Difficulties in backtracing a crash on XP
Hi,
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 :-(
Apparently it only crashes when snapping is enabled, but it looks like it's not the snapping code itself that's crashing. The bug report is here:
https://bugs.launchpad.net/inkscape/+bug/292077
It's been around at least since v0.46, according to this report.
Thanks,
Diederik
PS: If you want to have a try at reproducing it yourself, then please use revision 20049 or older. Newer revisions snap less often and are therefore more difficult to break.
On 11/9/08, Diederik van Lierop <mail@...1689...> wrote:
For the last three months (!!!), on and off, I'm fighting with a crash that fits this description precisely: windows only, no gdb only. For me it crashes intermittently when I arrow-key a path with markers in one of my files. It may or may not be connected with snapping and/or markers; even this I couldn't figure out with certainty. I now have an idea which may allow us to debug such crashes; if it works out I will let you know.
For now, one piece of advice I can give you is this: in inkscape_crash_handler, place abort() as the first line. This will make a crash to exit immediately. Without it, with my crash at least, screen updates continued while Inkscape displayed the "crash occurred" window, which made printf debugging incredibly difficult. With this change, there's no crash dialog, and it exits immediately as soon as it crashes.
On Sat, Nov 15, 2008 at 8:38 AM, Diederik van Lierop <mail@...1689...> wrote:
Wow, if this is indeed the bug I've been struggling with (will check today), you are my hero! Thanks a lot!
This has happened with other bugs before. Windows compiler seems to use a different memory layout, so pointers which hit forbidden memory on one platform land into valid memory on another.
Again, likely because the debugger somehow changes the memory layout of the program it runs. This is just a common sense guess of course, I know very little about executables.
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.
On 11/10/2008 08:30 PM, Richard Hughes wrote:
Since it was probably pointers that created the problem in the first place, I doubt you want any more of them. </badpun>.
:-)
I tried that, but all I got was two empty calls and two calls to some windows stuff. I already messed a bit with the crash handler to no avail, but I will give DebugBreak() a try.
That sounds like fun ;-).
Thanks for educating me (and probably some others too?), I will have another try!
Diederik
participants (5)
-
bulia byak -
Diederik van Lierop -
Jon A. Cruz -
Preben Soeberg -
Richard Hughes