This will prevent any other threads from being run, and you can explicitly choose which thread to run (with "thread [threadnumber]").
It lets you make your race condition a bit more deterministic.
21 June 2009 at 11:29
I had a problem with gnome-bluetooth's wizard, a couple of days ago, that I couldn't reproduce when running under gdb. Turns out that I'm too slow at typing or something, and the problem was a race (though a slow one).
There's a few tips and tricks in this class material. The one I was interested in was: (gdb) break foobar_new (gdb) commands thread apply all bt continue end
Then, every time you hit that break point, you'll get a backtrace, and the program will continue. I fixed that bug I saw :)
"gdb trick"
4 Comments -
Clearly you never had to debug evolution. thread apply all bt is burned into my brain, still, getting on 8 years later...
18 June 2009 at 18:31
I know thread apply all bt very well, the trick here is the fact that you can get the backtrace for a breakpoint without stopping the software.
18 June 2009 at 19:03
Try out http://sourceware.org/gdb/wiki/PythonGdb .
You write some nice python scripts :)
18 June 2009 at 19:24
For some cases, it is also handy to use:
set scheduler-locking on
This will prevent any other threads from being run, and you can explicitly choose which thread to run (with "thread [threadnumber]").
It lets you make your race condition a bit more deterministic.
21 June 2009 at 11:29