Next: Non-Stop Mode, Up: Thread Stops
In all-stop mode, whenever your program stops under gdb for any reason, all threads of execution stop, not just the current thread. This allows you to examine the overall state of the program, including switching between threads, without worrying that things may change underfoot.
Conversely, whenever you restart the program, all threads start
executing. This is true even when single-stepping with commands
like step
or next
.
In particular, gdb cannot single-step all threads in lockstep. Since thread scheduling is up to your debugging target's operating system (not controlled by gdb), other threads may execute more than one statement while the current thread completes a single step. Moreover, in general other threads stop in the middle of a statement, rather than at a clean statement boundary, when the program stops.
You might even find your program stopped in another thread after continuing or even single-stepping. This happens whenever some other thread runs into a breakpoint, a signal, or an exception before the first thread completes whatever you requested.
Whenever gdb stops your program, due to a breakpoint or a signal, it automatically selects the thread where that breakpoint or signal happened. gdb alerts you to the context switch with a message such as ‘[Switching to Thread n]’ to identify the thread.
On some OSes, you can modify gdb's default behavior by locking the OS scheduler to allow only a single thread to run.
set scheduler-locking
modeoff
, then there is no
locking and any thread may run at any time. If on
, then only the
current thread may run when the inferior is resumed. The step
mode optimizes for single-stepping; it prevents other threads
from preempting the current thread while you are stepping, so that
the focus of debugging does not change unexpectedly.
Other threads only rarely (or never) get a chance to run
when you step. They are more likely to run when you ‘next’ over a
function call, and they are completely free to run when you use commands
like ‘continue’, ‘until’, or ‘finish’. However, unless another
thread hits a breakpoint during its timeslice, gdb does not change
the current thread away from the thread that you are debugging.
show scheduler-locking