inkscape crashes, blank error message box, corrupted backup and original save

[jack_spratt]

Using 0.46 on PCLinuxOS.

I'm not exactly sure of the cause of this particular crash, but it had been crashing whenever i tried to ungroup objects of certain groups so i may have done that and triggered it. Regardless, once it had crashed a blank error message box popped up and then closed after a few seconds of its own accord. The generated backup file would not open either after this crash, exhibiting the same behaviour with the blank error box, and the original file itself, which had been recently saved, wont open either. Thus all copies of the work were corrupted.

The files (backup and original copy) will open and appear to render well on firefox and other image viewing software, but inkscape just wont open them.

Attached are the files in question, just some drafts for logos and stuff.

[Marcin Floryan (mfloryan)]

On Linux in SVN build the first file opens OK though it takes a good while. Trying to open the second file crashes Inkscape quite solid freezing my whole system for a good while too so it must be doing something nasty - running out of memory seems to be the issue here. In particular with this message:

terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc

Emergency save activated!

Emergency save document locations:
  /tmp/inkscape-
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
Aborted

[Marcin Floryan (mfloryan)]

Inkscape starts taking some 132M of memory but when the second file is opened it plummets to over 2G and sucks up all the CPU. I did manage to catch a little callstack when it finally crashed - if it helps:

#0 0x00002b5d02b80b45 in raise () from /lib64/libc.so.6
#1 0x00002b5d02b820e0 in abort () from /lib64/libc.so.6
#2 0x00002b5d026fed34 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib64/libstdc++.so.6
#3 0x00002b5d026fcce6 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00002b5d026fcd13 in std::terminate () from /usr/lib64/libstdc++.so.6
#5 0x00002b5d026fcdfa in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0x00002b5d026fd299 in operator new () from /usr/lib64/libstdc++.so.6
#7 0x000000000081ab9c in std::vector<Path::path_lineto, std::allocator<Path::path_lineto> >::_M_insert_aux (this=0x6a18278, __position=
      {_M_current = 0x2b5da9150010}, __x=@0x7fffb02a9290) at /usr/include/c++/4.2.1/ext/new_allocator.h:91
#8 0x000000000081847b in Path::AddPoint (this=<value optimized out>, iPt=@0xffffffff, mvto=<value optimized out>)
    at /usr/include/c++/4.2.1/bits/stl_vector.h:605
#9 0x0000000000820c57 in Path::ConvertEvenLines (this=0x6a18240, treshhold=0.0005376376373040343) at livarot/PathConversion.cpp:769
#10 0x0000000000830bb2 in Path::Coalesce (this=0x6a18240, tresh=0.0021505505492161372) at livarot/PathSimplify.cpp:1176
#11 0x000000000049e5bd in sp_offset_set_shape (shape=0x5e2c9e0) at sp-offset.cpp:595
#12 0x000000000049a7ba in SPObject::emitModified (this=0x4101440, flags=127) at /usr/include/sigc++-2.0/sigc++/signal.h:832
#13 0x00000000004888de in CGroup::onModified (this=0x61ff5e0, flags=92) at sp-item-group.cpp:683
#14 0x000000000049a706 in SPObject::emitModified (this=0x5eb0700, flags=95) at sp-object.cpp:1359
#15 0x00000000004888de in CGroup::onModified (this=0x5eaeaf0, flags=28) at sp-item-group.cpp:683
#16 0x000000000049a706 in SPObject::emitModified (this=0x5e69c40, flags=31) at sp-object.cpp:1359
#17 0x00000000004888de in CGroup::onModified (this=0x5e04c30, flags=28) at sp-item-group.cpp:683
#18 0x000000000049a706 in SPObject::emitModified (this=0x5ab7e00, flags=31) at sp-object.cpp:1359
#19 0x00000000004888de in CGroup::onModified (this=0x55ae9a0, flags=28) at sp-item-group.cpp:683
#20 0x00000000004a7627 in sp_root_modified (object=0x19feaa0, flags=27) at sp-root.cpp:568
#21 0x000000000049a706 in SPObject::emitModified (this=0x19feaa0, flags=27) at sp-object.cpp:1359
#22 0x0000000000454faa in SPDocument::_emitModified (this=0x132bc00) at document.cpp:662
#23 0x0000000000455176 in SPDocument::_updateDocument (this=0x132bc00) at document.cpp:809
#24 0x000000000045523f in sp_document_ensure_up_to_date (doc=0x132bc00) at document.cpp:827
#25 0x0000000000457979 in sp_file_open (uri=@0x7fffb02a9b40, key=<value optimized out>, add_to_recent=true, replace_empty=true) at file.cpp:197
#26 0x000000000045a1f7 in sp_file_open_dialog (parentWindow=<value optimized out>) at file.cpp:500
#27 0x00000000007b4783 in sp_action_perform (action=0x1333d90, data=0x0) at helper/action.cpp:181
#28 0x00002b5cfcc6dd2f in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0
#29 0x00002b5cfcc801fd in ?? () from /usr/lib64/libgobjec...

[sas (sas-sas)]

I ran both files through a script that removes non-SVG markup (and does some other other minor clean-up), and the resulting files open in Inkscape without problem (though they may have lost some editability, since all the Inkscape markup has been stripped out). This suggests that the problem is caused by sodipodi/inkscape attributes rather than the SVG itself.

I'm attaching a zip file containing the stripped-down SVG files.

[su_v (suv-lp)]

Based on the backtrace, same as e.g.
Bug #189784 “std:bad_alloc thrown after adding linked offset to graphic”
<https://bugs.launchpad.net/inkscape/+bug/189784>

-> likely the same as tracked more recently in:
Bug #345371 “stroked and scaled Linked Offset text causes a crash upon open file”
<https://bugs.launchpad.net/inkscape/+bug/345371>

[su_v (suv-lp)]

Both files (comment #1, comment #2) open without crash in current trunk 0.48+devel r12170 on OS X 10.7.4

(inkscape trunk grabs huge amounts of RAM while loading each of the files, and especially the second one took a couple of minutes until it finally opened in the document window and successfully was rendered on-canvas)

[Beluga (buovjaga)]

No crashes with current build either. I guess this could be closed.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15073 (GTK3)