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
thread apply all bt
Then, every time you hit that break point, you'll get a backtrace, and the program will continue. I fixed that bug I saw :)
Clearly you never had to debug evolution. thread apply all bt is burned into my brain, still, getting on 8 years later...
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.
Try out http://sourceware.org/gdb/wiki/PythonGdb .
You write some nice python scripts :)
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.
Post a Comment