Inkscape: A Vector Drawing Tool

trunk: hang (crash in gdb) on quit after live-previewing color-effect based extensions

Reported by ~suv on 2013-01-26
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
High
Unassigned

Bug Description

Steps to reproduce:
1) launch current trunk (from gdb) with default preferences
2) open 'cars.svgz' from the examples directory installed with inkscape
3) open 'Extensions > Color > Randomize…'
4) toggle 'Live Preview' on and off twice
5) close extensions dialog
6) quit

Expected result:
Inkscape quits.

Actual result:
Inkscape either hangs (after notifying about a crash on the console), or crashes right away (usually if launched from gdb).

Tests with archived builds:
- not reproduced with r11965 and earlier revisions
- reproduced with r11973 and later revisions
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/11973>

Reproduced on:
- Mac OS X 10.5.8 (i386), r11973 and later revisions
- OS X 10.7.4 (64bit), r11973 and later revisions
- Ubuntu 12.10 (64bit VM), r12063

Any attempts to narrow down what kind of SVG structure (layers, objects in root, object types) and/or style attributes (gradients, filter effects) triggers the crash have failed so far. The generated backtraces also slightly differ (possibly based on timing i.e. on how much time spent between the different "clicks").

Same issue was reported by vlada on #irc (AFAIK on Ubuntu 12.10, custom SVG files not publicly available).

~suv (suv-lp) wrote :

Full backtrace with Inkscape 0.48+devel r12063 on OS X 10.7.4

Dependencies:
- GTK+/Quartz 2.24.14 + patches from git
- gtkmm 2.24.2
- glib 2.34.3
- glibmm 2.34.1
- libsigc++ 2.2.10

description: updated
description: updated
jazzynico (jazzynico) wrote :

Confirmed on Debian testing, Inkscape trunk revision 12065.

Changed in inkscape:
status: New → Triaged
~suv (suv-lp) wrote :

The same file also hangs (or crashes) when applying a coloreffect extension (one without 'Live Preview') directly, or - if applying worked well - then the crash occurs on quit.
(Reproduced e.g. with 'Extensions > Color > Black and White')

jazzynico (jazzynico) on 2013-01-29
tags: added: blocker
~suv (suv-lp) wrote :

See also the comments in similar report Bug #1113635 “Color effects crash Inkscape 75% of the time”: the revision numbers I mention in the original description here are likely as inconsistent (or bogus) as discussed in bug #1113635.

Craig Marshall (craig9) wrote :

I have been trying to debug this on Win7, and can fairly reliably reproduce the crash on r11972, but cannot make it crash using r11971. I've made many attempts, and two clean builds of each rev just as a sanity check.

That revision made changes to color interpolation filters, and it seems to affect around 22 or so files, so I'm currently trying to narrow it down further.

Craig Marshall (craig9) wrote :

After further work, I have narrowed this down to a single line in revision 11972:

Line 134 of src/sp-filter.cpp is a new addition in this revision and it says:

object->readAttr( "style" ); // struct not derived from SPItem, we need to do this ourselves.

Now, with this line, the original test case crashes, without it, it doesn't.

Craig Marshall (craig9) wrote :

PS: Anyone know what the comment means?

Tavmjong Bah (tavmjong-free) wrote :

The "build" function for an element reads the corresponding XML node to fill in the structures variables. After doing this, it calls the parent structure's "build" function and so forth. Most structures that represent SVG elements in Inkscape are derived from SPItem. SPItem handles the reading in of the "style" attribute. But SPFilter is not derived from SPItem, being directly derived from SPObject, so the "style" attribute is not read in. We need to know the value of the attribute "color-interpolation-filters" to decide if we need to interpolate the color in sRGB or linearRGB space, thus the call to object->readAttr( "style" ).

Tavmjong Bah (tavmjong-free) wrote :

I have produced a simple file that exhibits the crashing behavior. It consists of a single blurred rectangle. Using the Color->Randomize effect as described above on the file results in a crash about a third of the time when the file is closed (waiting longer to close the file seems to increase the frequency of the crashes). Removing the two lines with 'inkscape:collect="always"' seems to prevent the crashing.

My guess is that reading the 'style' attribute in a <filter> element is creating a structure that is improperly garbage collected. But this is only a guess as I don't know how the garbage collector works.

jazzynico (jazzynico) wrote :

Related: Bug #1161003 "Segfault, assertion failed when running extensions".

Martin Owens (doctormo) wrote :

Can anyone else reproduce this bug on trunk? r12524, the code mentioned about in sp_filter has changed quite a bit and the proposed line is now 100 lines out from where it was. We should get three testers to go over the above STRs before we close this though.

Please do test.

~suv (suv-lp) wrote :

Possibly (but not with 100% certainty, due to the nature this bug has manifested itself to me) fixed with Johan's style-related changes in rev 12452, 12470.

Tests with various archived builds on OS X 10.7.5:
- reproduced repeatedly (but not consistently) with revisions 12451 and earlier,
- not reproduced (so far) with r12470 and later.
Repeated tests run via command line (see also comment #3):

$ inkscape -f /usr/share/inkscape/examples/car.svgz --verb="org.inkscape.color.blackandwhite" --verb=FileQuit

Martin Owens (doctormo) wrote :

suv, I put the bug up for testing on the list too. So far with lots of different builds, we have no error. I'm calling for a fixed status.

~suv (suv-lp) wrote :

On 2013-09-17 17:12 +0200, Martin Owens wrote:
> suv, I put the bug up for testing on the list too. So far with lots
> of different builds, we have noerror. I'm calling for a fixed
> status.

<opinion>Back in January, this bug abruptly ended my efforts (and motivation) to develop extensions for Inkscape -> I'm a bit wary to close it as 'Fix Released' yet</opinion> (especially since the exact cause is unknown, as is what might have fixed it).

@JazzyNico - since you had been able to reproduce it with older builds, what's your take?

@all - any news wrt to the very similar related reports?
Bug #1113635 “Color effects crash Inkscape 75% of the time”
Bug #1161003 "Segfault, assertion failed when running extensions"

Martin Owens (doctormo) wrote :

Frell, I tried to put it into "Incomplete" and launchpad is bitching at me.

OK so we have a bug that no one can reproduce on current trunk, where the suspected code has changed notably since it would crash. We need to put this into "Incomplete" until the bug appears again. Otherwise we're keeping a blocker going for myth and spooky feelings it might not be fixed.

Oh and remove blocker from the tags.

Changed in inkscape:
status: Triaged → Fix Committed
status: Fix Committed → Incomplete
Martin Owens (doctormo) on 2013-09-18
tags: removed: blocker
jazzynico (jazzynico) wrote :

> Bug #1113635 “Color effects crash Inkscape 75% of the time”
Not reproduced on Windows XP with r12526.

> Bug #1161003 "Segfault, assertion failed when running extensions"
Still crashes, not only when an extension is applied, but also when selecting the drawing.

Bug reports updated.

jazzynico (jazzynico) wrote :

> but also when selecting the drawing.
In GDB only...

jazzynico (jazzynico) wrote :

> @JazzyNico - since you had been able to reproduce it with older builds, what's your take?

Difficult to say. I can't even reproduce the bug with 12451...

Alvin Penner (apenner) wrote :

Windows XP, Inkscape rev 12549
 - I cannot reproduce the crash

~suv (suv-lp) on 2013-09-21
Changed in inkscape:
milestone: 0.49 → none
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers