[TRUNK] Crash when to redo gradient mesh

Bug #1614181 reported by Alexey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
High
Tavmjong Bah

Bug Description

Inkscape 0.91.0+devel+15066+77, OS Xubuntu 16.04 x64

Steps to reproduce:
1) Create a circle.
2) Add a gradient mesh.
3) Undo.
4) Redo.
5) Crash.

Console output:
Empty Mesh, No Draggers to Add
Emergency save activated!

Revision history for this message
Alexey (allkhor) wrote :
Revision history for this message
jazzynico (jazzynico) wrote :

Not reproduced on Windows XP, Inkscape 0.92.x branch rev. 15043.

tags: added: crash gradient-mesh
Changed in inkscape:
importance: Undecided → High
Revision history for this message
Alexey (allkhor) wrote :

Reproduced on Windows 7 x64, Inkscape 0.92pre1_64bit r15016

Revision history for this message
su_v (suv-lp) wrote :

On OS X 10.7.5:
- not reproduced with lp:inkscape/0.92.x r15024, r15043
- not reproduced with lp:inkscape rev <= 14793
- reproduced with lp:inkscape rev >= 14795

Possibly somehow (?) exposed with the changes in rev 14795 for GTK3 (the refactoring for GTK3 from the hackfest 2016 was mostly reverted in lp:inkscape/0.92.x which could explain why the crash does not reproduce with builds of the stable release branch as described).

Revision history for this message
jazzynico (jazzynico) wrote :

Also reproduced on Xubuntu 16.04, lp:inkscape rev. 15071.
GDB trace attached.

Changed in inkscape:
milestone: none → 0.93
status: New → Triaged
tags: added: regression
Revision history for this message
jazzynico (jazzynico) wrote :
Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

This appears to be due to a non-complete undo save. The redo does not restore the gradient. Why it causes crashes with the new GTK3 refactoring is a mystery (and might be a red herring).

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

The undo/redo code for mesh gradients should be working now in trunk (r15135). The main change is that the mesh node array (SPMeshNodeArray) is not cleared before reconstructing if the size of the mesh has not changed. This allows draggers to remain valid after changes that don't change the array size whether the changes come from dragging or changing the stop color. In this way we don't need to distinguish between a change to the XML that is due to dragging or changing the stop color, and that from an undo/redo operation.

Revision history for this message
su_v (suv-lp) wrote :

<off-topic>
lp:inkscape/0.92.x r15090 ("Backport trunk r15135. Fix undo/redo for mesh gradients.") fails to compile if build is not configured to use C++11. Proposed diff for affected users:
https://gist.github.com/su-v/38f6fd87c54f06f426fffcd88ff8fd29
</off-topic>

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

Undo/redo should also now work in 0.92.x.

Revision history for this message
jazzynico (jazzynico) wrote :

Proposing to apply the patch from comment #9 to lp:inkscape/0.92.x (if I remember correctly, it should not require C++11).

Changed in inkscape:
assignee: nobody → Tavmjong Bah (tavmjong-free)
milestone: 0.93 → 0.92
status: Triaged → Fix Committed
Revision history for this message
jazzynico (jazzynico) wrote :

Patch from comment #9 applied to lp:inkscape/0.92.x rev. 15093.

Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

Sorry about that... Thanks su_v and jazzynico.

Bryce Harrington (bryce)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.