Is it possible to halt the execution of all other threads when reaching a breakpoint in gdb?

Question

So, as soon as I hit a breakpoint in some thread, is it possible to halt other threads until I continue?

Answer 1

When your program stops under gdb for whatever reason, such as reaching breakpoint, all the threads of execution will stop, not just the current thread.

The issue is that when you then step through the code in one thread other threads may execute more then one step. Another problem is that other threads stop in the middle of a statement rather than at a statement boundary so it may look a bit messy.

In addition to that, once 'your' thread stops if other thread is blocked in system call, the system call will return prematurely, so you will get funny results unless you specifically code in a way where you check for this and restart the blocking call after signal.

You can find more info in Debugging with GDB - Section 5.4 Stopping and Starting Multi-thread Programs that can be found in Documentation section of gdb web site.

Edit: Looks like Non-stop mode is what you're after. Looks like this version has a section 5.4.2 discussing Non-stop mode, that the version on gnu site does not have.

Answer 2

That is the default for GDB. to enable Non-Stop Mode use set non-stop on.

Answer 3

In all-stop mode (the only mode supported by currently released versions) GDB will stop all threads as soon as any thread stops (due to a breakpoint or a signal).

When you continue the stopped thread, all other threads will also continue, unless you do set scheduler-locking on. Note that any of step, next, etc. continues current (and thus all other) thread (after setting a temporary breakpoint in appropriate place, e.g. on the next line for next command).

Perhaps you want to be able to single-step stopped thread without resuming all the other threads? In that case, set scheduler-locking on is the answer.

Beware: if another thread is holding a lock, you turn scheduler-locking on, and your current thread also requires the same lock, your program will wait indefinitely. This often comes up if one of the threads is inside malloc/realloc, and your current statement tries to allocate some memory.

Also don't forget to set scheduler-locking off before continue, otherwise only the current thread will make any forward progress.