Moving nodes with snapping causes crash.

Bug #292077 reported by Kaspar on 2008-11-01
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Nominated for 0.47.x by Kaspar

Bug Description

When dragging the nodes so that they snap to the other nodes or intersections of lines, I get crashes.
Sometimes it takes 1-4 drags, sometimes I get away even with 40, but no more than that.

I've experienced the same behaviour with Inkscape 0.46, Inkscape19908-0809221503 and Inkscape20105-0810312141.

I have XPSP3, quad core.

I've attached the file that's giving me the headaches.
Try dragging the nodes of the triangles, so that they snap to the intersections of vertical and horizontal lines and to other nodes.
Give it some time, it takes 1-40 drags.


Kaspar (kaspartorn) wrote :

Confirmed on XP using rev. 20149, but not on Linux.

Alvin Penner (apenner) wrote :

- running Win32 Inkscape20150
- I have seen crashes, but cannot reliably reproduce them

- somewhat off the topic, it is very difficult to "import" this file. File | Open _always_ works, at least for the initial load. File | Import most often, usually, causes a crash with the message :

return code: -1073741819

(inkscape.exe:4004): Gtk-WARNING **: Could not find the icon 'edit-select-all'.
The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:

Emergency save activated!

Kaspar (kaspartorn) wrote :

I tried Importing the file and found the following to happen consistently - the first import goes OK, when I delete the imported graphics and import the same file again, I get this message:

"Inkscape encountered an internal error and will close now.
Automatic backups of unsaved documents were done to the following locations:
        New document 1.2008_11_10_01_10_44.0.svg"

I don't get the missing icon warning.
What is this theme/icon missing exactly?

Alvin Penner (apenner) wrote :

actually, the missing icon warning can be ignored, it happens all the time if you run Inkscape from DOS.

however, for future reference, if you are running Windows, then you can get more detailed error messages by running Inkscape from DOS and using the techniques outlined in : or

The more recent post (node 63) is a bit more user-friendly. In either case you will see what was sent to stderr output.

Preben S (prsodk) wrote :

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?

Kaspar (kaspartorn) wrote :

Don't know if it's multiprocessor problem...


This is a showstopper for me though if it doesn't get better soon.

I have previously reported a bug with item drag+snapping crash in 0.46:

When I tried the development builds, this one seemed to go away, but the node crashing remains.

Hello Kaspar,

Ill do everything I can to get this one fixed, but this is a tough one. I cannot pin-point the location of the crash because I cannot get a decent backtrace. Could you try obtaining a backtrace yourself, as described here ? Maybe you're more lucky than me.

Please note that for some reason it's impossible to open a file when running Inkscape through gdb. As a workaround you should run

(gdb) run c:\temp\Kolmnurgad.svg

instead of just

(gdb) run



LucaDC (dicappello) wrote :

Please, consider that:
Bug #272730 2008-09-21
Bug #274423 2008-09-25
Bug #283211 2008-10-14 (mine)
Bug #292077 2008-11-01
seem all duplicates of the same bug. I'm glad to see that, eventually, it has been taken seriously under consideration.
I experimented this problem from Distribution 0.46 to almost all following developement versions.

I don't agree that the drag-snapping problem has gone.
My computer is a single processor Pentium 4 3.2GHz, XP-SP3, 2GB RAM, so it can't be related to multiprocesor.

As written on my report, I also could not easily reproduce the problem in a sistematic way and had difficoulties in generating a backtrace as the problem doesn't happen when I need it!
Could you give more specific indications on how backtrace needs to be produced to be useful?
Do you think it's possible that when running under gdb the problem doesn't come out? (or maybe it comes out in a different manner...)

Thanks for all your great work.

Kaspar (kaspartorn) wrote :

I can't find the right dbg file.
On this page it's written:

"For each of the runnable .7z builds in this directory, there is a corresponding InkscapeNNNNN-YYMMDDHHMM-dbg.7z."

But there's only one dbg file available:

Or am I looking in the wrong place?

No, you're looking in the right place. Please use the "fulldbg" file, and see if the bug is reproducible there too. If a newer version with full debug info is needed then it must be compiled; I'll ask Bob Jamison to build a new one.

Kaspar (kaspartorn) wrote :

Well it seems I need a step by step guide what to do.

I've downloaded the "fulldbg", but have no idea what the rest of the process is.

Do I double-click on the "gdb.exe"?
What then?

Hello Kaspar,

You should start up the command prompt (Start -> Run -> CMD), go the the directory in which you've unpacked the fulldbg file (using the "cd" command, e.g "cd c:\inkscape"), and then continue reading the text below (copied from

If you experience a crash in Inkscape, here is how to report it. For each of the runnable .7z builds in this directory, there is a corresponding InkscapeNNNNN-YYMMDDHHMM-dbg.7z. Unpack the .dbg file from one of these into your inkscape installation directory, and run inkscape with:

gdb inkscape

Then at the gdb prompt:

(gdb) symbol-file inkscape.dbg

Then run it with:

(gdb) run c:\temp\your-file-name.svg

Now perform the steps to reproduce your crash. Once it crashes:

(gdb) bt

and you will get a "backtrace" listing. Send this to us on the bug tracker, the mail list, or best of all, just visit the online group and chat with us there. Bugs reported that way can be fixed in a few days. Sometimes with a good bug report they are fixed in a few hours. Helping us in this way is a good way to participate and get to know a good online community.

LucaDC (dicappello) wrote :

This is what I did:
- copy gdb.exe under Inkscape directory (the same where inkscape.exe is);
- copy inkscape.dbg under Inkscape directory (the same where inkscape.exe is);
- open a command prompt on Inkscape directory;
- run gdb inkscape;
- under gdb type "symbol-file inkscape.dbg";
- under gdb type "run";
- use Inkscape and make it crash...
- under gdb type "bt";
Unfortunately I could not cause a crash under gdb yet, so I can't give indications on how to extract and send the backtrace, but I expect getting a text file.

The inkscape.dbg is inside Inkscape0806201805-fulldbg.7z archive.

I hope this helps you.

Hi Luca,

You didn't state this explicitly, but both the inkscape.exe and inkscape.dbg files must be from the same .7z file, you cannot mix these with newer or older versions. Probably you knew this already, but I mention this just in case....

Kaspar (kaspartorn) wrote :

All right!

I dragged those nodes for a half hour - no crash.
If it wouldn't be so slow this way, it would be a very stable working environment :)

I'll try again later...

PS. The instructions on the webpage need to be a lot more elaborate, I think there are other commandlineophobes like me out there.

1. Click "Run"
2. Write "cmd", enter
3. Write "cd c:\program files\inkscape", enter
4. Write "gdb inkscape", enter
5. ...

Kaspar, feel free to write some more detailed instructions and post them on our wiki.

BTW, there's a freshly compiled windows version with full debugging capabilities available:

LucaDC (dicappello) wrote :

I start thinking that working speed could be important: usually I get more crashes when I'm in a hurry and work fast with Inkscape.
Maybe it's difficoult to get crashes under gdb because you are forced to work _slowly_.
One thing that could happen when you work faster is that you start new operations before some updates of previous ones have been completed or because the debugger forces some "synchronization-stops" in the program execution.
If you think this is a silly thing, please forget it.

Diederik, tanks for the new debug version: I'm downloading it and I'll try it asap.
Thanks also for pointing out the old.gdb-new.exe inconsistence: I supposed it was not ok but I couldn't get the right .gdb for latest snapshots so I tried using the old one "just to see". Anyway, this hasn't been a problem so far as I couldn't get a crash yet.

LucaDC (dicappello) wrote :

Yesterday I worked under gdb with the latest debug version, and no crashes at all. And I tried to work as usual, also if I had to exit gdb to add new layers without locking the program (I left it 100% CPU for 1 hour while on lunch, but it was still stuck).
Also, I reported a bug (Bug #296778) about cut-paste objects that become pngs that happens only when running under gdb but not when under inkscapec: how can we get a backtrace if the program behavior changes so much under debugger?
In any case, I couldn't have Kolmnurgad.svg crash so far, with or without gdb. That's not to say that the problem doesn't exist, of course, as I've already experienced on files of mine; simply that there are some boudaries conditions we are probably missing.

Now I'll try this debug version for a while without gdb, to have it crash at least once. If not, there's no point in trying under gdb.

Well, at least I've found the location of the crash now, so we're close to having it fixed! Bisecting our repository learned me that this bug first occurred in rev. 18995. The crash occurs at line 784 of sh-shape.cpp (line number is only valid for rev. 18995):

     Geom::Point tang2 = curve_it2->unitTangentAt(0);

I'll notify some other developers who might be familiar with this code

I just fixed it myself. It wasn't too hard after all :-)

Please test a build with rev. number 20205 or newer and let me know if this problem indeed has disappeared.

Kaspar (kaspartorn) wrote :

Just tested the version 20212 - so far no crashing!


I hope this issue won't come back.

So, what was the key to solving this one? The difference between a regular and a debug version?

You're welcome! I'm keeping my fingers crossed too ;-)

The different behavior between the two versions made it impossible to find the bug the easy way, i.e. using a debugger. Therefore I was forced to compile and test about 10 different revisions of Inkscape inbetween rev. 18000 and 21000, which takes a lot of time and is boring. But in the end the problem is solved, which makes it all worthwile!

Changed in inkscape:
status: New → Fix Released

BTW, thanks for your effort too!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments