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.
Hi,
-----Original Message----- From: Diederik van Lierop [mailto:mail@...1689...] Sent: 10 November, 2008 04:20 To: inkscape-devel Subject: [Inkscape-devel] 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
I have just reported to the bug tracking that:
I have not been able to reproduce the error, and I don't have problems moving snapping nodes in other files.
On XPSP3 single core.
Can it be a multiprocessor problem?
Preben
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.
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11/9/08, Diederik van Lierop <mail@...1689...> wrote:
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 :-(
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:
Well, never mind. I just fixed this myself (see rev. 1698 of 2geom, and rev. 20205 of Inkscape). unitTangentAt() falsely assumed that pointAndDerivatives(t,n) always returns a vector of size n+1, and therefore tried to access elements outside the vector bounds.
Wow, if this is indeed the bug I've been struggling with (will check today), you are my hero! Thanks a lot!
These questions remain though:
- Why was this only a problem on Windows? No one has been able to reproduce
this on Linux.
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.
- Why wasn't it reproducible while debugging?
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.
On Nov 15, 2008, at 4:38 AM, Diederik van Lierop wrote:
- Why was this only a problem on Windows? No one has been able to
reproduce this on Linux. My hypothesis is that both platforms suffered from the same bug, but that Inkscape simply didn't die on Linux and kept running (on Windows Inkscape kept running too after the crash dialog, but only for a few seconds). Keeping Inkscape running is obviously good from a user perspective. However, it didn't even produce a warning on Linux, which is bad from a developers point of view. An out-of-bounds error should be screamed out loud!
This can often be caught by using valgrind.
_INKSCAPE_GC=disable valgrind --tool=memcheck inkscape
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.
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'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.
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.
- 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.
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