Bug 292077 is giving me quite some difficulties in pin-pointing it. It crashes Inkscape, but I can only reproduce it on Windows (not on Linux), and only when I'm _not_ running gdb. To make things worse it even requires quite some patience to reproduce it. How does one find the cause of such a bug? I've tried attaching gdb after the crash (is that possible at all?), and sprinkled around lot's of std::couts, but I didn't get any closer. I could use some pointers here :-(
Since it was probably pointers that created the problem in the first place, I doubt you want any more of them. </badpun>.
I've found that there are lots of little tricks needed to make mingw32 debugging possible. I'll try to list those that I think might be useful to you (in no particular order).
- gdb can attach to an already-running app. You can use either "gdb --pid=1234" or run the "attach 1234" command in an existing gdb.
- Bulia's advice about putting abort() in inkscape_crash_handler() would work, but I'd use DebugBreak() from the Win32 API instead. This'll get you a 'application crashed' popup. Do not close this popup, just move it out of the way and attach gdb to the crashed process.
- There are a few GUI wrappers around gdb which work on Windows. Don't bother with them; in my experience they cause you to spend more time debugging the debugger than debugging your app.
- If the crash is in Win32 code, you'll need Microsoft symbols to backtrace out of Win32 and then gdb symbols to backtrace through Inkscape. This presents a problem, since gdb can't load Microsoft pdb files. What I do is attach gdb as the primary debugger and then windbg in noninvasive mode as the secondary. When gdb breaks in, start the stack trace in windbg to get the necessary parameters to continue it in gdb.
- There are quite a few other useful tricks you can do with the two debuggers. In your case, see if it still crashes if windbg is attached as primary. If it does, then manually backtrace the stack by using gdb for symbol lookup ("info symbol").
- You may have noticed that compiling all of Inkscape with debug symbols creates object files that require several GB of physical RAM in order to be able to link them before the heat death of the universe. I leave -g off by default (but present in the link, otherwise you get nothing) which is enough for gdb to be able to bracktrace function names only. Once I know this, I then have to rebuild the files containing the functions I'm interested in with -g in order to get the line numbers and variables.
Hmm. That'll do for now. It would be probably by possible to write a book containing all the gotchas around debugging apps built with the GNU toolchain on Win32. It wouldn't be a very interesting book and nobody would buy it, but there you are.
Richard.