feImage crashes inkscape if filtered object is the same as referenced object

Nowadays this doesn't freeze Inkscape, but crashes.

Crash confirmed on Ubuntu 9.04, rev. 21460.

Backtrace attached.

It is still crashing.

Is it legal at all to have a feImage filter applied to the same object it uses as image source ? This creates an undesirable loop. Does the SVG spec forbid it? If not, how should that be handled/rendered?

Reproduced with r12812. This should be addressed for 0.49 if possible.

Updated GDB backtrace, on Crunchbang Waldorf with Inkscape trunk revision 12904.

Some related changes committed revision 12970 (http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12970): "Protect against infinate looping of new included hrefs".

Unfortunately it doesn't seem to fix the feImage loop.

The specification of feImageElement:

This filter primitive refers to a graphic external to this filter element, which is loaded or rendered into an RGBA raster and becomes the result of the filter primitive.

This filter primitive can refer to an external image or can be a reference to another piece of SVG. It produces an image similar to the built-in image source SourceGraphic except that the graphic comes from an external source.

https://www.w3.org/TR/SVG/filters.html#feImageElement

So I suppose you could make a case that this filter element isn't intended to be used on the same object, but there's nothing explicit. What do other svg editors/renderers do in this situation?

This introduce a loops in the rendering since it's the filtered object that's used to filter the object.
svg are not allowed to have any kind of loops, which should just stop the rendering.

If someone wants to tackle this, the proper fix for that kind of things would probably be to systematically use a derived class of URIReference for all linking "url()" attributes used in styles (URIReference is used by linked xlink:href and checks for loops ).

This patch partialy fix.
Still happends the recursion but is bloked at 33 steps and render ok and no crash. So I think is better than previous state. I dont know how to fix the recursion, done on the update method.

Also work on groups in the same way.

The recursion is forbidden by spec. All the code needed for it (to check for any causal loop) is in the URIReference::accept code, so as mentioned in comment #8, one just has to derive it to be used not only in xlink:herf refs, but also in url() ones, which will probably require some changes in style.cpp

Ok Mc, tanks for the reply, I think it over my knoweledge :(

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Moved to: https://gitlab.com/inkscape/inbox/issues/351
Closed by: https://gitlab.com/mray