Crash when undoing change to duplicated gradient

[Weeble]

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.

[Weeble (clockworksaint)]

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.

[su_v (suv-lp)]

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)

[jazzynico (jazzynico)]

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

[su_v (suv-lp)]

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.

[rickmastfan67 (rickmastfan67)]

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

[su_v (suv-lp)]

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?

[rickmastfan67 (rickmastfan67)]

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.

[Mc (mc...)]

Pushed a fix to r14345

[su_v (suv-lp)]

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.

[su_v (suv-lp)]

Backported to 0.91.x in rev 13811 and 13812.