Debugging multi-threaded programs

The GDB Debugger manual describes multi-threaded programs:

" ...a single program may have more than one thread of execution. The precise semantics 
of threads differ from one operating system to another, but in general the threads of a 
single program are akin to multiple processes — except that they share one address space 
(that is, they can all examine and modify the same variables). On the other hand, each 
thread has its own registers and execution stack, and perhaps private memory."

Debugging a multi-threaded program is broadly similar to debugging a single-threaded program, however a number of points must be borne in mind:

• A breakpoint may be set in any part of the program in the normal way. If the breakpoint is set in a function or method that was or will be started as a separate thread, then execution halts as normal when the breakpoint is hit. If the function or method executes in several threads, then execution halts each time the breakpoint is hit, no matter which thread it is in.
• When a thread stops, usually because a breakpoint or watchpoint is hit, then all currently executing threads stop. Only the thread that initiated the stop is guaranteed to stop at a source line. The other threads may stop anywhere, including part-way through a statement.
• The thread that initiated the stop becomes the currently active thread and the focus of debugging.
• The currently active thread is marked with an asterisk '*' in the Threads tab.
• When a thread is started with "Debug" [F8], "Next Step" [F7], "Step Into" [Shift+F7] or any other command that causes execution to begin, ALL stopped threads will re-start.
• A single step might not complete. It is possible for a breakpoint or another cause in another thread to halt execution before the first thread completes the step you requested.
• It is not possible to separately identify watched variables that have the same name, but which are in different threads; hence the program will stop when any instance of the watched variable changes. However, the thread in which the watched variable changed will become the current thread, and both the Local Variables tab and the Watches tab will show the values of the variables in that current thread.
• Unless you examine memory directly, the CPU window also operates on the current thread. Unlike Local Variables, Watches and Threads, the panes of the CPU window do not refresh automatically and you must click Refresh on each pane as appropriate.