Debugging in multithreaded systems

Debugging in multithreaded systems

[Paul Smith]

Can someone provide some insight on multithreaded debugging?

I'm trying to track down a really gnarly issue in a multithreaded system. 
I really need to control the way threads run while I'm debugging.

I'm using GDB 8.2.1 on a GNU/Linux (x86_64) system.

I'm setting 'set scheduler-locking step', which I thought would do what I
wanted: when I'm debugging only my thread under debug will run and other
threads are suspended: this is critical for me because if other threads run
they perturb the bug.

The problem is that the docs say that "step" mode will keep other threads
locked in "step" and will free them up for "continue", "until", and
"finish".

But the docs don't say anything about "next".

I had assumed that "next" would work like "step", but it appears that
instead it works like "finish" etc. and allows other threads to run :(.

I sort of get it because "next" is akin to stepping into a method then
calling "finish", but this is a big bummer because I'm debugging a C++
program and trying to step through every STL statement in every method,
etc. etc. is very time consuming.

Abstractly it would make much more sense (to me) if "next" worked like
"step" and kept the other threads locked out.

Am I missing something?  Is "next" supposed to work like "step"?  If not
could it be changed to do so?  Or, I guess, if there really is some useful
reason to have "next" allow other threads to run, a new scheduler-locking
mode for "next" could be added...?

For now I guess I'll (try to remember to) force "set scheduler-locking off"
and then back on again by hand each time.

Re: Debugging in multithreaded systems

[Jonah Graham]

On Thu, 6 Feb 2020 at 17:06, Paul Smith <psmith@gnu.org> wrote:

> Can someone provide some insight on multithreaded debugging?
>

I'll try - but I can't answer your underlying question about changing next
behaviour in this case.

1. Consider using non-stop mode instead of all-stop mode if supported:
https://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html#Non_002dStop-Mode
-
the key line is this:
"In non-stop mode, all execution commands apply only to the current thread
by default. That is, continue only continues one thread. To continue all
threads, issue continue -a or c -a." - so you can interrupt all threads,
and then just debug the one problematic thread. If course you need a system
that supports non-stop and I don't know which ones do and don't.
2. Try passing numeric argument to step to step multiple times at once.

HTH
Jonah