Color effects crash Inkscape 75% of the time

[Magnes]

Almost every time I use any of the color effects (to change tint for example) Inkscape crashes. I'm using trunk, it's like that since at least two months. Easy to reproduce: try using color effects several times on a complicated object with gradients.

[su_v (suv-lp)]

> (…) any of the color effects (…)
> I'm using trunk, it's like that since at least two months.

Based on the provided information (no sample SVG file), likely a duplicate of
- Bug #1106031 “trunk: hang (crash in gdb) on quit after live-previewing color-effect based extensions”
  <https://bugs.launchpad.net/inkscape/+bug/1106031>

[Magnes (magnesus2)]

Here is example SVG that crashes. Select the red bubble and from menu use Effects -> Color -> Less Hue (I'm not sure about the exact name of this menu item because I'm using language different from English). On the other elements it doesn't crash...

[jazzynico (jazzynico)]

Reproduced on Debian testing, Inkscape revision 12093.
The extension crashes when it is used on one group and then on a different one.

Backtrace attached.

[jazzynico (jazzynico)]

Also reproduced on Windows XP, Inkscape revision 12103. The application crashes with the following message (a bit different than the previous bt):

**
ERROR:src/document.cpp:835:void SPDocument::bindObjectToId(const gchar*, SPObject*): assertion failed: (g_hash_table_loo
kup(priv->iddef, GINT_TO_POINTER(idq)) != NULL)

[jazzynico (jazzynico)]

Reproduced on Windows XP, revision 10923, but not reproduced with revision 10785.
Still lots of commits, but that's all I have at hand today.

[su_v (suv-lp)]

Attaching console log with various backtraces, based on these steps:
1) launch inkscape
2) open 'test.svg'
3) open 'Extensions > Color > Randomize…'
4) deselect the options 'Lightness', 'Saturation'
5) repeatedly apply the extension (to the drawing itself)

The backtraces slightly vary, also the number of times needed to apply the hue randomize effect (possibly also a factor: timing in-between the repeated steps) - sometimes it crashes after the 3rd time, sometimes I can use the effect 12 or more times before the crash occurs. With my builds (OS X 107.4, GTK+/Quartz 2.24.14, glib2.34.3), the backtraces are more or less what I get with bug #1106031 (those aren't consistently identical either).

The last backtrace in the attached log file was the result of repeatedly applying the effect 'Less Hue' (~10 times), as originally described by the reporter, again without a current selection (affecting the drawing itself).

Console/gdb messages when crash occurs:
-----
(inkscape:57012): GLib-WARNING **: Idle source dispatched without callback
You must call g_source_set_callback().

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001020e3d85 in sigc::signal_base::~signal_base ()
-----
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff997cc26d in std::_List_node_base::unhook ()
-----
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001020e4470 in sigc::trackable::remove_destroy_notify_callback ()
-----
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000000f0
0x000000010035d6b0 in SPIPaint::isPaintserver (this=0xe8) at style.h:171
171 bool isPaintserver() const {return (value.href) ? value.href->getObject():0;}
-----
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00000001003a6b10 in sp_style_object_release (object=0x10a8ac4d0, style=0x0) at style.cpp:366
366 style->object = NULL;
-----
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff997cc26d in std::_List_node_base::unhook ()
-----

[jazzynico (jazzynico)]

> The backtraces slightly vary, also the number of times needed to apply the hue randomize effect.

Yes, it's a bit difficult to test. Even with your steps, you sometimes have to quit and restart the application to test again and trigger the crash.

> Reproduced on Windows XP, revision 10923, but not reproduced with revision 10785.

Just noticed I wrote something wrong: it can now be reproduced with 10785, but not with 10568 (tested again 4 times, 40 effects applied each time). I guess we can't rely on it, due to the difficulty we have to reproduce the crash sometimes.

Attached is a reduced test file that crashes quite easily with revision 12103.

[su_v (suv-lp)]

> I guess we can't rely on it, due to the difficulty we have to
> reproduce the crash sometimes.

Agreed - while trying to confirm the range of revisions you mention in comment #6, I'm getting so inconsistent results that it seems impossible (at least with my current skill set) to narrow down which range of revisions may trigger it or not.

[su_v (suv-lp)]

> Attached is a reduced test file that crashes quite easily with revision 12103.

Haven't been able to reproduce this yet - what an odd bug (like with bug #1106031 - I already spent lots of efforts to bisect that sample file there to narrow down which elements trigger it, and failed due to inconsistent result).

[Magnes (magnesus2)]

OK. Maybe this will help: the file I attached now (second test file) worked fine until I used blur on the first group of circles. Then it crashed right away when I tried to change it's color. (the first file I uploaded also uses blur for some elements)

[Magnes (magnesus2)]

PS. Removing blur makes it not crash again. So it is probably related to blur somehow. Maybe it's even crashing during drawing not applying the effect?

[jazzynico (jazzynico)]

Crash reproduced on Windows XP, Inkscape trunk revision 12451.
Not reproduced with revision 12526 (tested with both test.svg and test2.svg).

Closing fixed. Don't hesitate to reopen if you run into the same issue again with a recent trunk revision.