If I see the message "2" but not "3" I know the crash happened in some_piece_of_code2.

I also use GDB to get backtraces. Again, don't compile with -g. Not necessary at all! One of the problems with running Inkscape in gdb is that you cannot open a file with the file dialog: Inkscape will hang. I don't know the reason, but I do know a solution! Open the file through Inkscape's cmdline parameters:

D:\Inkscape\inkscape>gdb
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) file inkscape.exe inkscape.dbg
Reading symbols from D:\Inkscape\inkscape/inkscape.exe...(no debugging symbols found)...done.
Reading symbols from D:\Inkscape\inkscape/inkscape.dbg...done.
(gdb) run Tekening.svg
Starting program: D:\Inkscape\inkscape/inkscape.exe Tekening.svg

Nothing much can crash there, the assert checks that _widget is not NULL, and then the cast is valid aswell. So what crashed? What happens is that the setValue method is called for an object that does not exist. _widget is not NULL, but "this" is! this->_widget would crash. g_assert (this != NULL) would give an assertion message. (checked by adding " if (this==NULL) g_message("ja hoor"); " )

It is absurd to check for "this" to be non-NULL at the start of every method, so the bug is not in this method but in the function calling it! That's why we turn our attention to Inkscape::CanvasXYGrid::readRepr ().

readRepr is long, but we only have to look where it does something with a Scalar widget. It's the validateScalar functions. When we comment those out, the bug is solved. (it causes another bug with the specific SVG file, where Inkscape hangs when the grid spacing equals zero. validateScalar used to check for that...)
The strange thing is that the widgets are all created and initialized in the constructor of CanvasXYGrid. So perhaps readRepr is being called *during* construction of CanvasXYGrid, while the Scalar widget is still invalid? Using the g_message tip above I found out that the problem code was:

Problems running GDB

From an inexperienced user of GDB just trying to get backtraces, here is a tip I found running gdb.

I simply downloaded the latest version of Inkscape Dev full debug, extracted to a directory and ran gdb exactly as above from within the directory, only changing the name of the svg file.

Everything went exactly as above for "file inkscape.exe inkscape.dbg", however after executing the "run {filename.svg}" command, I received the following message;

Program received signal SIGSEV, Segmentation fault.
0x03de8cf1 in xslDebugStatus ()

This has stumped me once before, but this time I checked out the help menus, and found under "help running" that I could simply type "continue". I figured that xslDebugStatus was nothing to do with the Inkscape program itself, but more to do with gdb, and after typing "continue" it seems to run Inkscape under gdb as normal, allowing backtraces.

guard32.dll error

If you try to run gdb but it halts, complaining about guard32.dll, your Comodo Firewall installation is blocking gdb. Easiest way around this is to disable the Defense+ module completely -- open up Comodo Firewall, click on Defense+, Defense+ settings, set Security Level to "Disabled", and check "Deactivate the Defense+ permanently". Reboot.

Debugging Tips for Linux

Debugging Inkscape on Linux is most easily done using Eclipse (or any other IDE). When however a breakpoint is reached while Inkscape is in a pointer grab (for example when dragging a control point or drawing a path), then X will stop responding. If you want to debug in such a case then you'll have to use gdb from the console. In Fedora 10 you'll get to the console when pressing ctrl-alt-F5. Now enter

declare -x DISPLAY=":0"

and startup gdb to load Inkscape and the debugging symbols, set your breakpoints, and start Inkscape. Now you can switch back to X (ctrl-alt-F1) and interact with Inkscape. When Inkscape stops responding because it hit a breakpoint, switch back to the console and do your debugging.

If you happen to run into some issues with one of the Gtk+ libraries and want to step through its code using the debugger, you will have to install its debugging symbols. For Fedora 10 you can simply enable the fedora-debuginfo repository in /etc/yum.repos.d/fedora.repo and then use yum to install for example the "gtk2-debuginfo" and "glib-debuginfo" package. For other distros you'll find some usefull information here: