Inkscape crashes with "out of memory" when ungrouping

[Johan De Meersman]

I'm trying to edit a (probably very complex) .ai file. Importing works, but when trying to ungroup the master object, Inkscape starts eating more memory, then crashes with an "Out of memory" error.

Running the latest trunk (Inkscape 0.48.3.1 r (May 23 2012)), on Linux Mint Isadora (== Ubuntu Lucid) 32-bit with 4G of memory - but also happens with 0.48.2 r9819 (Oct 7 2011).

Steps to reproduce:
 * open PhaistosDiskTuxColor.ai
 * Import with default settings
 * Click object
 * Right click, select "Ungroup"

Here's the GDB output:

meersjo@soulcake-duck ~ $ gdb /usr/bin/inkscape
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/inkscape...(no debugging symbols found)...done.
(gdb) run SparkleShare/LBW-2012-Orgynisation/Hiking\ Tux/Filip/PhaistosDiskTuxColor.ai
Starting program: /usr/bin/inkscape SparkleShare/LBW-2012-Orgynisation/Hiking\ Tux/Filip/PhaistosDiskTuxColor.ai
[Thread debugging using libthread_db enabled]
[New Thread 0xb454ab70 (LWP 6105)]
[Thread 0xb454ab70 (LWP 6105) exited]

** (inkscape:6074): WARNING **: GC Warning: Out of Memory! Returning NIL!

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

Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()
(gdb) bt
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x01baf651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x01bb2a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x01b1752f in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#4 0x01b15465 in ?? () from /usr/lib/libstdc++.so.6
#5 0x01b154a2 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x01b155e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x08554dfd in Inkscape::XML::SimpleNode::SimpleNode(Inkscape::XML::SimpleNode const&, Inkscape::XML::Document*) ()
#8 0x085531b8 in Inkscape::XML::ElementNode::_duplicate(Inkscape::XML::Document*) const ()
#9 0x0854c36b in Inkscape::XML::SimpleNode::duplicate(Inkscape::XML::Document*) const ()
#10 0x08554d09 in Inkscape::XML::SimpleNode::SimpleNode(Inkscape::XML::SimpleNode const&, Inkscape::XML::Document*) ()
#11 0x085531b8 in Inkscape::XML::ElementNode::_duplicate(Inkscape::XML::Document*) const ()
#12 0x0854c36b in Inkscape::XML::SimpleNode::duplicate(Inkscape::XML::Document*) const ()
#13 0x08554d09 in Inkscape::XML::SimpleNode::SimpleNode(Inkscape::XML::SimpleNode const&, Inkscape::XML::Document*) ()
#14 0x085531b8 in Inkscape::XML::ElementNode::_duplicate(Inkscape::XML::Document*) const ()
#15 0x0854c36b in Inkscape::XML::SimpleNode::duplicate(Inkscape::XML::Document*) const ()
#16 0x082db857 in sp_item_group_ungroup(SPGroup*, _GSList**, bool) ()
#17 0x08559f58 in ?? ()
#18 0x00eaedcc in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#19 0x00ea1252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#20 0x00eb599d in ?? () from /usr/lib/libgobject-2.0.so.0
#21 0x00eb6db4 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#22 0x00eb7256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#23 0x00a2f3f5 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x0090d9b0 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x0090f32f in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x00904c74 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x008fe434 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#28 0x00e9f8b9 in ?? () from /usr/lib/libgobject-2.0.so.0
#29 0x00ea1252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#30 0x00eb55e6 in ?? () from /usr/lib/libgobject-2.0.so.0
#31 0x00eb6c33 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#32 0x00eb7256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#33 0x00a2b646 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#34 0x008f6a6d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#35 0x008f7e17 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#36 0x00bec39a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#37 0x00f245e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#38 0x00f282d8 in ?? () from /lib/libglib-2.0.so.0
#39 0x00f28817 in g_main_loop_run () from /lib/libglib-2.0.so.0
#40 0x008f83d9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#41 0x003063a7 in Gtk::Main::run_impl() () from /usr/lib/libgtkmm-2.4.so.1
#42 0x003061a2 in Gtk::Main::run() () from /usr/lib/libgtkmm-2.4.so.1
#43 0x08264ceb in sp_main_gui(int, char const**) ()
#44 0x0834d77a in Inkscape::NSApplication::Application::run() ()
#45 0x0826412a in main ()
(gdb)

[su_v (suv-lp)]

Not reproduced with Inkscape 0.48.3.1 r9886 (64bit) on OS X 10.7.4 (glib2 2.32.3, boehmgc 7.1):
Ungrouping is slow, inkscape consumes about 1.7 - 1.9 GB memory, but it is possible to ungroup the "master" object without crash.

Note: I even ungrouped it twice - the inner group contains individual 76550 objects (SVG file attached, original size: 30'774'827 bytes).

Please do clarify:
> Running the latest trunk (Inkscape 0.48.3.1 r (May 23 2012)), on Linux Mint Isadora

"0.48.3.1" is _not_ trunk but the latest bug-fix release of the stable 0.48 release branch (lp:inkscape/0.48.x) .
Trunk builds based on lp:inkscape should report '0.48+devel' as version, and - if built locally - the revision number of the last pull.

Which package and inkscape version / revision do you actually have installed?

[su_v (suv-lp)]

Crash also not reproduced with latest trunk build (0.48+devel r11520) on OS X 10.7.4 (64bit).

<off-topic>
Current trunk appears much slower than stable 0.48.x when ungrouping the large inner group with 76550 individual objects.
</off-topic>

[Johan De Meersman (vegivamp+launchpad)]

> Please do clarify:
> Which package and inkscape version / revision do you actually have installed?

Both :-) I normally use 0.48.2 r9819 from the official Ubuntu backports repo; but I installed 0.48.3.1 from the Inkscape Stable PPA, and the package was called inkscape-trunk - thus my confusion. I'll now be working on 0.48.3.1 permanently.

Sounds like it simply can't allocate the memory it wants on my 32-bit platform then - but I'd expect it to handle that slightly more graceful than blowing up :-)

Incidentally, I can open the file you uploaded and work on it, so thanks for that :-)

[su_v (suv-lp)]

Crash also not reproduced with Inkscape 0.48.3.1 r9886 (32bit) on Mac OS X 10.5.8 (i386) (glib2 2.28.8, boehmgc 7.1)

-> doesn't seem to be a basic Inkscape failure/bug on 32bit systems either.

[su_v (suv-lp)]

Crash also not reproduced with recent 32bit trunk build (0.48+devel r11518) on Mac OS X 10.5.8 (i386).

[su_v (suv-lp)]

Similar to e.g. Bug #444940 “Too many heap sections”

Which version of libgc do you have installed on Linux Mint Isadora (== Ubuntu Lucid)? Probably a duplicate of bug #168914 and should be fixed with libgc >= 7.1.

[Johan De Meersman (vegivamp+launchpad)]

Yes, I indeed do have libgc 6.8. Upgrading that is too much trouble for an issue I'm not likely to run into again in the near future, though, so I'm afraid I won't be able to confirm that it was indeed the issue. It does sound likely, though - feel free to close this.