Debugging in multithreaded systems

[Paul Smith <psmith@gnu.org>]

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.