crash with filter effect + blur

[Mourad Mokrane]

Inkscape0801270322 on Windows vista Home Premium

- create a rectangle
- apply Diffuse Lighting filter effect (filter is applied to source graphic by default)
- then open the Fill and Stroke dialog and try to add some blur to the object

At this point, Inkcape crashes with the "Inkscape encountered an internal problem..." window.

[prkos (prkos)]

I can confirm on WinXP, 25th Jan build

(diffuse filter still doesn't work, it just displays black all over and around object)

[Mourad Mokrane (momo-lumenstudio)]

And yes, I get the same strange behaviour of the Diffuse Lighting filter, black color over object.

[Tom Davidson (tjd-mit)]

Both bugs confirmed under Linux (Fedora Core 6) using a recent SVN (17176, Jan 25 2008)...

[Emir ONUK (e-onux)]

there is a problem on intersection area of between two filtered shape.

[Marcin Floryan (mfloryan)]

I was just experimenting with filters on a single rectagle - adding Blurr and Diffuse Lighting crashed Inkscape with the following output (might help debug)

SVN version build updated at 2008-02-01

*** glibc detected *** ./inkscape: free(): invalid next size (normal): 0x0000000005e01300 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b7e9f25c21d]
/lib64/libc.so.6(cfree+0x76)[0x2b7e9f25df76]
/usr/lib64/libpango-1.0.so.0(pango_parse_markup+0x242)[0x2b7e9b6346a2]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a8b49c1]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a8b7379]
/usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x10f)[0x2b7e9b861d2f]
/usr/lib64/libgobject-2.0.so.0[0x2b7e9b8745f6]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x855)[0x2b7e9b875c55]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit+0x83)[0x2b7e9b876043]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a9d2b96]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a9d2bc9]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a9d622b]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_widget_set_parent+0x1fc)[0x2b7e9a9da11c]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_box_pack_start+0xf5)[0x2b7e9a7ff995]
./inkscape[0x6e3da7]
./inkscape[0x49c66a]
./inkscape[0x48ccfe]
./inkscape[0x4a97a7]
./inkscape[0x49c5b6]
./inkscape[0x44f35a]
./inkscape[0x44f526]
./inkscape[0x44f5cf]
./inkscape[0x519f8e]
./inkscape[0x51a462]
./inkscape[0x5ddfba]
/usr/lib64/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x34)[0x2b7e9a565e04]
/usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x10f)[0x2b7e9b861d2f]
/usr/lib64/libgobject-2.0.so.0[0x2b7e9b8747c8]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x855)[0x2b7e9b875c55]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit+0x83)[0x2b7e9b876043]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a834626]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_combo_box_set_active_iter+0x5c)[0x2b7e9a835a2c]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a835b41]
/usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x10f)[0x2b7e9b861d2f]
/usr/lib64/libgobject-2.0.so.0[0x2b7e9b8741fd]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x855)[0x2b7e9b875c55]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit+0x83)[0x2b7e9b876043]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_widget_activate+0x68)[0x2b7e9a9d73b8]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_menu_shell_activate_item+0x146)[0x2b7e9a8d7fb6]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a8d9976]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a8cbbbf]
/usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x10f)[0x2b7e9b861d2f]
/usr/lib64/libgobject-2.0.so.0[0x2b7e9b8745f6]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x589)[0x2b7e9b875989]
/usr/lib64/libgobject-2.0.so.0(g_signal_emit+0x83)[0x2b7e9b876043]
/usr/lib64/libgtk-x11-2.0.so.0[0x2b7e9a9d3025]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_propagate_event+0xd2)[0x2b7e9a8c4ef2]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2a5)[0x2b7e9a8c5e95]
/usr/lib64/libgdk-x11-2.0.so.0[0x2b7e9ad7e7cc]
/usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x1e4)[0x2b7e9cf0c204]
/usr/lib64/libglib-2.0.so.0[0x2b7e9cf0f4fd]
/usr/lib64/libglib-2.0.so.0(g_main_loop_run+0x1b7)[0x2b7e9cf0f7f7]
/usr/lib64/libgtk-x11-2.0.so.0(gtk_main+0xa3)[0x2b7e9a8c6263]
./inkscape[0x449a26]
./inkscape[0x44982b]
/lib6...

[Niko Kiirala (kiirala)]

Here's a patch to prevent the crash. However, as this results in blur slider moving around without doing a thing, it's not a solution for this. Maybe it's a part of the solution.

There are two different things that I'd consider as viable solutions for this:

1) Disable the blur slider when the object already has a non-blur filter applied

2) Do something sensible when object has non-blur filter applied. One thing that could work: if the last element in the filter chain is blur, modify it. If the last element is non-blur, add blur as last element. It's not good for all situations, but I don't believe there exists an automatical solution that would be good in all situations.

I don't know much about this UI side of Inkscape code, so it'd likely take me quite a long time to find the correct place to put either one of these fixes in.

[bbyak (buliabyak)]

> 2) Do something sensible when object has non-blur filter applied. One
> thing that could work: if the last element in the filter chain is blur,
> modify it. If the last element is non-blur, add blur as last element.
> It's not good for all situations, but I don't believe there exists an
> automatical solution that would be good in all situations.

What you described sounds perfect to me, that's more or less what I
was planning all along

[bbyak (buliabyak)]

Niko: now that I have some more work experience with that, I'd like to slightly change the plan you outlined above: instead of only looking at the last element, try to find the last blur in the stack (which may be not last as in my example, where a displacement map is on top of blur) and modify it. I think this will make sense in most cases, because usually, when you have blur, it is visible as blur in the final result, even if it is displacement-mapped, color-mapped etc by another primitive on top of it. Therefore, adjusting the amount of this not-quite-blur-but-still-blur is usually what the user really wants. Makes sense?

[Niko Kiirala (kiirala)]

Yes, makes sense. Then again, with effects like examples/lighting_effects.svg it would be better to not search the filter stack for blur. Well, nevertheless: both ways have their drawbacks. Guess I could just as well implement it so, that it modifies the last blur in stack.

[Niko Kiirala (kiirala)]

Fixed in SVN trunk revision 18763