inkscape bzr 13290 crashes when trying to edit a gradient position (rev >= 13223)

Bug #1309050 reported by Sergio Benjamim on 2014-04-17
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
High
Liam P. White
Experimental
High
Liam P. White

Bug Description

Trying to edit a gradient position, when I move it inkscape crashes. The file I'm trying to edit is attached.

Ubuntu 13.10 - Linux sergio-X750JB 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Inkscape compiled from lp:inkscape
bzr commit 13290

Happens too with 13288 from PPA:
Installed: 1:0.48+devel+13288+47~ubuntu13.10.1

---

Debug information (more attached):

(inkscape:4023): Gtk-CRITICAL **: IA__gtk_widget_get_visible: assertion 'GTK_IS_WIDGET (widget)' failed

(inkscape:4023): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed

Program received signal SIGSEGV, Segmentation fault.
Geom::Point::operator*= (this=this@entry=0x7fffffffdf60, m=...) at 2geom/point.cpp:209
209 _pt[i] = x * m[i] + y * m[i + 2] + m[i + 4];
(gdb) bt
#0 Geom::Point::operator*= (this=this@entry=0x7fffffffdf60, m=...) at 2geom/point.cpp:209
#1 0x00000000004928c3 in operator* (rhs=..., lhs=...) at ./2geom/utils.h:58
#2 SPDesktop::w2d (this=<optimized out>, p=...) at desktop.cpp:1798
#3 0x00000000004f2a4d in sp_knot_handler_request_position (event=0x5e542e0, knot=0x2f5cdb0) at knot.cpp:355
#4 0x00000000009ff606 in Inkscape::UI::Tools::sp_event_context_snap_watchdog_callback (data=0x6271cf0,
    data@entry=<error reading variable: value has been optimized out>) at ui/tools/tool-base.cpp:1366
#5 0x00007ffff2032f13 in g_timeout_dispatch (source=source@entry=0x64dc370, callback=<optimized out>, user_data=<optimized out>)
    at /build/buildd/glib2.0-2.38.1/./glib/gmain.c:4450
#6 0x00007ffff20323b6 in g_main_dispatch (context=0x12a9f30) at /build/buildd/glib2.0-2.38.1/./glib/gmain.c:3065
#7 g_main_context_dispatch (context=context@entry=0x12a9f30) at /build/buildd/glib2.0-2.38.1/./glib/gmain.c:3641
#8 0x00007ffff2032708 in g_main_context_iterate (context=0x12a9f30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.38.1/./glib/gmain.c:3712
#9 0x00007ffff2032b0a in g_main_loop_run (loop=0x3136d00) at /build/buildd/glib2.0-2.38.1/./glib/gmain.c:3906
#10 0x00007ffff6bd2277 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00000000004743ac in sp_main_gui (argc=1, argv=0x7fffffffe3b8) at main.cpp:1075
#12 0x00007ffff1208de5 in __libc_start_main (main=0x458470 <main(int, char**)>, argc=1, ubp_av=0x7fffffffe3b8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffe3a8) at libc-start.c:260
#13 0x0000000000470caf in _start ()

Sergio Benjamim (sergio-br2) wrote :
Sergio Benjamim (sergio-br2) wrote :
Sergio Benjamim (sergio-br2) wrote :

I can reproduce this issue, here other debug information.

description: updated
description: updated
su_v (suv-lp) wrote :

Reproduced with r13290 on OS X 10.7.5.

tags: added: crash gradient regression
Changed in inkscape:
importance: Undecided → High
milestone: none → 0.91
status: New → Confirmed
su_v (suv-lp) wrote :

Steps to reproduce (from scratch):
1) launch current trunk with new prefs, default new document
2) draw two rectangles
3) change fill to gradient for each of them
4) select both, switch to the gradient tool ('G')
5) grab start node of one gradient and drag it near a stop of the other gradient

Expected result:
The two stops are "merged"

Actual result:
crash

Based on tests with archived builds on OS X 10.7.5:
- not reproduced with rev <= 13222
- reproduced with rev >= 13224
the regression was likely introduced with the refactoring of SPKnot in rev 13223:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13223>

summary: - inkscape bzr 13290 crashes when trying to edit a gradient position
+ inkscape bzr 13290 crashes when trying to edit a gradient position (rev
+ >= 13223)
Liam P. White (liampwhite) wrote :

Reproduced with r13291 on Ubuntu 12.04.

Issue: bad casting.

1364│ gpointer knot = dse->getItem2();
1365│ if (knot && SP_IS_KNOT(knot)) {
1366│-> sp_knot_handler_request_position(dse->getEvent(), SP_KNOT(knot));
1367│ }
-------------------------------src/ui/tools/tool-base.cpp------------------------------------------------

#0 Inkscape::UI::Tools::sp_event_context_snap_watchdog_callback (data=0x64d62d0) at ../../inkscape-wo-tag/src/ui/tools/tool-base.cpp:1369
(gdb) set $knot = dse->getItem2()
(gdb) print $knot
$3 = {gpointer (Inkscape::UI::Tools::DelayedSnapEvent * const)} 0x0

Additionally, ~suv has stated that the same line of code has had issues in stable.

su_v (suv-lp) wrote :

On 2014-04-18 04:51 +0100, Liam P. White wrote:
> Additionally, ~suv has stated that the same line of code has had
> issues in stable.

This refers to a discussion in #inkscape-devel:

 su_v : and that merging of gradient knots is a special case
 su_v : (I do recall that either that, or separating merged stops (drag with shift) used to produce console warnings in the past)
 su_v : stable when merging two stops:
 su_v : (inkscape:76365): GLib-GObject-WARNING **: invalid cast from `GtkWindow' to `SPKnot'
 su_v : or
 su_v : (inkscape:76365): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `SPKnot'
 su_v : trunk < 13223 doesn't produce those warnings though
 su_v : (13222)
LiamW : Then the crash is actually a good thing
LiamW : Not for the end user
LiamW : But for the debugger
 su_v : seems that http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12000 stopped the warnings in trunk
 su_v : (test with archived builds: warning with r11997, no warning with rev >= 12000)
LiamW : that was probably not a good thing to kill the warnings
 su_v : r11997:
 su_v : (inkscape-11997:76618): GLib-GObject-WARNING **: invalid cast from `SPCtrlLine' to `SPKnot'
 su_v : or r11995:
 su_v : (inkscape-11995:76601): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `SPKnot'
LiamW : dynamic_cast<SPKnot*>(void* randomMemory)
LiamW : basically

jazzynico (jazzynico) wrote :

Also reproduced on Windows XP, Inkscape trunk revision 12293.
Not reproduced when Snapping is disabled.

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

Root cause of this bug is that the snap delay mechanism is broken.
The DelayEvent is passed pointers to objects that may have been deleted once the delay callback triggers, because the DelayEvent does not do proper refcounting of the objects passed.
To fix this, separate Delay Events classes have to be written for each of the delay event types. Then the constructor/destructor of those events can do proper referencing, such that the referenced objects are not deleted.

Johan Engelen (johanengelen) wrote :

A temporary fix is disabling the snap delay, by commenting out line 285 in.knot.cpp.
("//sp_event_context_snap_delay_handler(knot->desktop->event_context, NULL, (gpointer) knot, (GdkEventMotion *)event, Inkscape::UI::Tools::DelayedSnapEvent::KNOT_HANDLER);")

Changed in inkscape:
status: Triaged → Fix Committed
assignee: nobody → Liam P. White (inkscapebrony)
Liam P. White (liampwhite) wrote :

Reverting fix in trunk since other regressions arise due to it.

Changed in inkscape:
status: Fix Committed → In Progress
Liam P. White (liampwhite) wrote :

I think I did it correctly this time. Fixed in lp:inkscape, r13472; lp:inkscape/experimental, r13442

Changed in inkscape:
status: In Progress → Fix Committed
Bryce Harrington (bryce) on 2015-02-21
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers