Crash editing gradient of clone parent

[MarkDaniel]

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

[su_v (suv-lp)]

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!

[su_v (suv-lp)]

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)]

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)]

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

[Pablo Trabajos (pajarico)]

Ok, it crashes.

[Yaroslav Zubkov (yzubkov)]

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)]

Reproduced again on Windows XP, Inkscape trunk revision 12188.

[Johan Engelen (johanengelen)]

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)]

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

[Johan Engelen (johanengelen)]

Fixed the symptom in trunk rev 13465.

[Tavmjong Bah (tavmjong-free)]

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)]

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)]

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

[Antonio Ospite (ospite)]

This seems to have been fixed, I cannot reproduce the crash in 0.92.3; should the status be changed to "Fix committed"?

[Alvin Penner (apenner)]

on Windows 10, Inkscape 0.92.3 (2405546, 2018-03-11)
this operation generates the following message, but no crash:

** Message: POINT_RG_MID2 bug trigger, see LP bug #453067

[Tavmjong Bah (tavmjong-free)]

Should be fixed, see https://gitlab.com/inkscape/inkscape/issues/130

[Adam Belis (adambelis)]

Closing because [becosu its fixed in 1.1].
https://gitlab.com/inkscape/inkscape/issues/130
Closed by: https://gitlab.com/adambelis