Crash editing gradient of clone parent

Bug #453067 reported by MarkDaniel on 2009-10-16
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
High
Unassigned

Bug Description

In the attached file editing the radial gradient in the Event Wiring box causes a crash.

Steps to reproduce:
 - Open the attached file
 - Select the gradient edit tool
 - Click on the pink gradient behind 'Event Wring' in the top ScriptExecutor (This is a clone parent)
 - Pull the outer horziontal handle to the right and then the inner horizontal handle to the left
 - The application exits with an erre 'Runtime Error' 'The application haas requested the Runtime to terminate it in an unusal way'

This bug is completely reproduceable in 0.46 and 0.47pre3

Related branches

su_v (suv-lp) on 2009-10-16
tags: added: crash gradient node-editing
su_v (suv-lp) wrote :

reproduced with Inkscape 0.46+devel r22476 on OS X 10.5.8

console msgs:
terminate called after throwing an instance of 'std::out_of_range'
  what(): vector::_M_range_check

Emergency save activated!

Changed in inkscape:
importance: Undecided → High
status: New → Confirmed
su_v (suv-lp) wrote :

adding minimal test case: drag the gradient nodes of the original (middle square) in attached file as noted in the bug description:

1) Select the gradient edit tool
2) Click on the radial gradient of the middle square (this is a clone parent)
3) Pull the outer horizontal handle to the right and then the inner horizontal handle to the left

Result: Inkscape crashes 'after throwing an instance of 'std::out_of_range''.
Editing the gradient of the duplicate (upper square, no clones attached) doesn't lead to a crash.

Pablo Trabajos (pajarico) wrote :

Do you mean like this? It doesn't crash on pre4 but the stop holders are not moved when I move the gradient center.

su_v (suv-lp) wrote :

1) pull the horizintal outer handle to the right
2) drag one of the middle stops to the left

Pablo Trabajos (pajarico) wrote :

Ok, it crashes.

summary: - Crash editing gradient
+ Crash editing gradient of clone parent
Yaroslav Zubkov (yzubkov) wrote :

I can confirm that this crash happens for me on:
Linux 3.0.0-15-generic
KDE 4.7.4
Inkscape 0.48.2 r9819
My backtrace is just like the one attached above. Pesky little bug!

jazzynico (jazzynico) wrote :

Reproduced again on Windows XP, Inkscape trunk revision 12188.

Changed in inkscape:
status: Confirmed → Triaged
Johan Engelen (johanengelen) wrote :

I have trouble fixing this bug :(
The problem is that a clone creates its own SPItems, that in turn references the cloned object's gradient. Upon editing of gradient stops, the gradient is forked if more objects reference it. Because of the clone, every step in updating the gradient stops will fork the gradient (gradient is forked, clone sees it's clonee changed, so updates itself and references the forked gradient immediately). So there is a lot of fork spam, visible in the XML editor.
Somehow, things are not correctly updated when a fork happens. (it is not very clear from function names which methods can potentially fork a gradient)
Disabling gradient forking removes the crasher, but that's not a good fix obviously.

Johan Engelen (johanengelen) wrote :

GDB gives *a ton* of "use after free" breaks when dragging knots....

Johan Engelen (johanengelen) wrote :

Fixed the symptom in trunk rev 13465.

Tavmjong Bah (tavmjong-free) wrote :

A clone needs its own SPItems because the <use> element can have different styling which cascades down into the clone's elements. However, a gradient should not need to be forked. It is either inside the cloned object, and thus the same for all clones or it is defined outside and cascades down.

Gradient inside cloned object:

<rect id="myClonedRect" fill="url(#myGradient)" ... />
<use xlink:href="#myClonedRect" ... />
<use xlink:href="#myClonedRect" ... />

Gradient outside cloned object:

<rect id="myClonedRect" .../> <-- No fill
<use xlink:href="#myClonedRect2" fill="url(#myGradient1)" ... /> <-- Different gradients
<use xlink:href="#myClonedRect2" fill="url(#myGradient2)" ... />

If a gradient is defined relative to the bounding box its transform should be handled in the rendering code (like masks and clips).

Johan Engelen (johanengelen) wrote :

The gradient need not be forked, but Inkscape has no way of knowing this. The clone references the gradient (increasing the refcount) and there is no way to determine which of the ref counts are for clones of a certain object and which aren't. Already the code does a calculation to determine how many of the gradient refs are due to an item itself; however, an item has no way (afaik) of determining if it is being cloned or not. If an item can determine how many times it is cloned, the problem is easy to solve.

Johan Engelen (johanengelen) wrote :

"the problem" in #14 being the forking spam.

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

Other bug subscribers