Book review: The Art of Debugging with GDB, DDD and Eclipse (Chapter 5).

Debugging in a multiple-activities context

Debugging Client/Server Network Programs

This section presents only a short example. The most important tricks to remember are:

GDB had a jump command, but in general you should use this command with caution.

Including errno.h can be useful for your debugging, as is the use of the strace program for checking the result of system calls.

In really complex network debugging cases, you might want to use a program to track individual TCP/IP packets.

Debugging threaded code

The POSIX standard Pthreads is used for the example in this section.

Modern operating systems use timesharing to manage multiple running programs in such a way that they appear to the user to execute simultaneously. After a certain timeslice, processes are preempted and a context switch occurs. Because you do not know the order in which threads will be scheduled, the debugging is more difficult.

Threads vs. processes: a thread is designed to occupy less memory and its context switch time is less than that for processes. Threads are therefore also sometimes called leightweight processes.

The global variables of the parent program in a threaded environment are shared by all threads and serve as the main method of communication between the threads.

Preemptive thread management policy: a thread in a program can be interrupted at any time by another thread. This makes bugs not always reproducible.

Each time a new thread is created, GDB announces it. To know what each thread is doing, you can use the GDB info threads command. The asterisk in the output shows you what thread you're in. You can inspect the stack of any thread by switching to that thread and then issuing the bt command:

  thread 3
  bt

Some other examples which should speak for themselves:

  break 88 thread 3
  break 88 thread 3 if x==y

In DDD, select Status | Threads, and a window will pop up, displaying all threads in the manner of the GDB info threads. You can click a thread to switch the debugger's focus to it. In DDD, you cannot make a breakpoint thread-specific, so you have to use the DDD Console and issue GDB commands.

Eclipse constantly displays your thread list, as opposed to having to request it, as in DDD. The call stack is shown in the thread list. In Eclipse, you can set a breakpoint for a specific thread: right-click and select 'Filtering'.

Debugging parallel applications

• Shared memory: Multiple CPUs all have access to some common physical memory.
• Message passing: code running on each CPU can only access that CPU’s local memory, and it communicates with the others by sending messages.

Message-Passing Systems

The book's examples use MPI.

GDB allows you to dynamically attach the debugger to an already-running process, using the process number: first find process number, then

  gdb programname 2776

Shared-memory systems

• True Shared Memory: OpenMP, internally makes use of threads.
• Software Distributed Shared-Memory Systems

Quite some difficulties arise when debugging this kind of programs. Pay attention!

Extended Example

Most important message from this example: pay attention with line numbers! They are not always what you think they are! For the rest, nothing too interesting here...