It occurs also on the current gradient stop and any color change.

Sometimes it also freezes my Kubuntu !

ivan

________________________________ De : Diederik van Lierop <mail@...1689...> À : Ivan Louette <ivan_louette@...48...> Cc : "Inkscape-devel@lists.sourceforge.net" <Inkscape-devel@...349...orge.net> Envoyé le : Samedi 2 Juillet 2011 15h11 Objet : Re: [Inkscape-devel] Crash when changing gradient opacity

On 07/02/2011 02:57 PM, Ivan Louette wrote: Rev 10355. Draw an object ; Open Fill and Stroke dialog ; Apply any gradient ; go to next stop and try to change color opacity : It display the change on the shape and crash togheter.

Confirmed: here's a backtrace

Thread [1] 5915 (Suspended : Signal : SIGSEGV:Segmentation fault)        Gtk::Widget::get_is_drawable() at 0x3f0bf40beb        Inkscape::UI::Widget::ColorPreview::setRgba32() at color-preview.cpp:59 0x111e3bd        sp_gradient_vector_color_changed() at gradient-vector.cpp:1,193 0x12e7643        g_closure_invoke() at 0x315100e34e        0x315101f200        g_signal_emit_valist() at 0x31510289d2        g_signal_emit() at 0x3151028b72        ColorSelector::_released() at sp-color-selector.cpp:267 0xf3bad0        ColorNotebook::_entryReleased() at sp-color-notebook.cpp:598 0xf369ae        g_closure_invoke() at 0x315100e34e        <...more frames...>

Regards,

Diederik

On Jul 2, 2011, at 6:30 AM, ~suv wrote:

https://bugs.launchpad.net/inkscape/+bug/804243

Any widget changes in the dialog result in a crash:

• switch color mode tab
• drag 'Offset' slider
• enter RGBA string in hex
• ...

(AFAICT regression introduced with the merge of the cairo-rendering branch. Only happens when using the "deprecated" gradient editor dialog, instead of using the gradient tool to edit the gradient on-canvas)

This seems like the type of problem where running valgrind, in addition to the backtrace, can be a help. This is a command line I commonly use:

_INKSCAPE_GC=disable valgrind --tool=memcheck --num-callers=24 --log-file=valrun.txt ./inkscape

The first part sets the environment variable to disable our garbage collection, so that valgrind won't get too confused. Another key is "--log-file" which captures the output.

The main intent of running valgrind would be to catch corruption before it gets to the point that it has cascaded into an actual crash. A backtrace will let you know what happened in the direct stack when a crash has occurred. Valgrind tries to catch things much eariler than that.

In this case I see the following:

==32109== Invalid read of size 4 ==32109== at 0x26D8A7B: Gtk::Widget::get_is_drawable() const (in /opt/local/lib/libgtkmm-2.4.1.dylib) ==32109== by 0x26D8AB0: Gtk::Widget::is_drawable() const (in /opt/local/lib/libgtkmm-2.4.1.dylib) ==32109== by 0x765389: Inkscape::UI::Widget::ColorPreview::setRgba32(unsigned int) (in ./inkscape) ==32109== by 0x4EC577: sp_gradient_vector_color_changed(SPColorSelector*, _GtkObject*) (in ./inkscape) ==32109== by 0x42642B4: g_closure_invoke (in /opt/local/lib/libgobject-2.0.0.dylib)

Looking into that last Inkscape method, it's not good: void ColorPreview::setRgba32 (guint32 rgba) { _rgba = rgba;

if (is_drawable()) queue_draw(); }

Combining those, it seems fairly clear that some invalid pointer was used as "this" for that ColorPreview method (note that the is_drawable() function takes no parameters). And finally, looking at the next-to-last line in sp_gradient_vector_color_changed seems to be at least somewhat responsible for the problem.