Debugging in multithreaded systems
Paul Smith <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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.