Crash when undoing change to duplicated gradient

Bug #1417173 reported by Weeble
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Critical
Unassigned

Bug Description

Repro steps:

1. Start Inkscape 0.91
2. Draw a rectangle
3. Object -> Fill and Stroke (The fill tab is selected.)
4. Click the "Linear gradient" button.
5. Click the "Create a duplicate gradient" button.
6. Press ctrl+z for undo.

Results:

Inkscape crashes. (The main window closes. No dialog appears. The file is not saved.)

This reproduces 100% for me.

I'm using Inkscape 0.91 64-bit on Windows 7.

Revision history for this message
Weeble (clockworksaint) wrote :

I don't have the time or resources to debug this under Windows, but when I get home later I'll try to repro on Linux and see if I can include a backtrace.

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

Reproduced on OS X 10.7.5 with Inkscape 0.91 r13725 and 0.91+devel r13892:

** (inkscape:23217): WARNING **: Incomplete undo transaction:

** (inkscape:23217): WARNING **: Event: Added #<Element:0x0x1149a3850> to #<Element:0x0x116a1d0d0> after beginning

** (inkscape:23217): WARNING **: Event: Set attribute id to "linearGradient4279" on #<Element:0x0x116a1d0d0>

** (inkscape:23217): WARNING **: Event: Set attribute id to "stop4281" on #<Element:0x0x116a21fd0>

** (inkscape:23217): WARNING **: Event: Set attribute id to "stop4283" on #<Element:0x0x116a21ee0>

** (inkscape:23217): WARNING **: Event: Set attribute id to "linearGradient4271" on #<Element:0x0x116a1d0d0>

** (inkscape:23217): WARNING **: Event: Set attribute id to "linearGradient4285" on #<Element:0x0x116a1d670>

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000000c8
SPPaintServer::isSwatch (this=0x0) at ../../src/sp-paint-server.cpp:42
42 return swatch;
(gdb)

Changed in inkscape:
importance: Undecided → High
milestone: none → 0.91.1
status: New → Confirmed
tags: added: gradient undo
tags: added: crash
Revision history for this message
jazzynico (jazzynico) wrote :

Also reproduced on Crunchbang Waldorf, Inkscape trunk rev. 13893. Same backtrace.

Changed in inkscape:
status: Confirmed → Triaged
Revision history for this message
su_v (suv-lp) wrote :

Based on tests with archived builds (on OS X 10.7.5):
- no crash with rev <= 12050,
- crash with rev >= 12054;
the regression seems to be related to changes in 12052-12054:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/12054

The "Incomplete undo transaction" was already recorded with earlier revisions, but Inkscape didn't crash.

Revision history for this message
rickmastfan67 (rickmastfan67) wrote :

I just got nailed by this bug as well. Except it was done in the stroke part. But I did try it with the fill window as well and the backtrace was the same with both.

Don't know if this will help as well, but I've attached my BT as well. Would have done the 'BT full', but I get no extra info (trace is identical to the basic BT).

Anyways, it's a complete crash on my system with no emergency save by Inkscape. Because of that, you could lose a lot of work if you don't save often if you get hit by this bug.

Inkscape 0.91 r13725 x64 (MSI)
Windows 7 SP1 x64

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

On 2015-05-17 11:30 (+0200), rickmastfan67 wrote:
> Anyways, it's a complete crash on my system with no emergency save
> by Inkscape. Because of that, you could lose a lot of work if you
> don't save often if you get hit by this bug.

Inkscape not creating an emergency saved file not reproduced with 0.91 r13725 and 0.91+devel r14156 on OS X 10.7.5 (unless of course Inkscape is run from gdb - it never creates an emergency save file here when triggering a crash while running from gdb).

For now, not raising bug importance to 'Critical' ... could someone please test again on Windows, whether this could be a platform-specific 'critical' crash?

Revision history for this message
rickmastfan67 (rickmastfan67) wrote :

Well, are there any current trunk builds for Windows x64 out there?

I know that when I noticed this bug in 0.91, I wasn't running gdb when I had it crash. Thankfully, I had just saved my file right before I started to play with the gradients.

Anyways, I just double checked with 0.91 to see if it was for sure not making an emergency save if there had been changes. I just moved a node in my file, added the 'duplicated' gradient, hit the undo button, and it crashed w/ no emergency save. Just a complete crash to the desktop.

su_v (suv-lp)
Changed in inkscape:
importance: High → Critical
Revision history for this message
Mc (mc...) wrote :

Pushed a fix to r14345

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

Based on tests with recent archived trunk builds (on OS X 10.7.5), the fix for this report was committed in two steps:
* r14324 by Tavmjong Bah prevents the crash, but the selected object references a non-existent gradient after undo - it renders e.g. without fill;
* r14345 by Mc fixes the "lost" gradient: the object is now visually unchanged after undoing the gradient duplication, as expected.

The console messages about "Incomplete undo transaction" are still present.

Changed in inkscape:
milestone: 0.91.1 → 0.92
status: Triaged → Fix Committed
tags: added: backport-proposed
Revision history for this message
su_v (suv-lp) wrote :

Backported to 0.91.x in rev 13811 and 13812.

Changed in inkscape:
milestone: 0.92 → 0.91.1
tags: removed: backport-proposed
jazzynico (jazzynico)
Changed in inkscape:
milestone: 0.91.1 → 0.92
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.