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

Bug #195320 reported by Felipe "Juca" Sanches on 2008-02-25
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
High
Unassigned

Bug Description

This bug was introduced in revision 17484
http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=17484

steps to reproduce:

* create a star
* open filter effects dialog
* create a new filter
* add an Image filter primitive
* select the star
* click on "Selected SVG Element"
* apply the filter to the star

inkscape freezes

Changed in inkscape:
assignee: nobody → felipe-sanches
status: New → Confirmed
Niko Kiirala (kiirala) wrote :

Nowadays this doesn't freeze Inkscape, but crashes.

Changed in inkscape:
importance: Undecided → High
jazzynico (jazzynico) wrote :

Crash confirmed on Ubuntu 9.04, rev. 21460.

Backtrace attached.

su_v (suv-lp) on 2009-09-23
tags: added: crash
removed: freeze

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?

ScislaC (scislac) wrote :

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

Changed in inkscape:
milestone: none → 0.49
jazzynico (jazzynico) on 2014-01-08
Changed in inkscape:
status: Confirmed → Triaged
jazzynico (jazzynico) wrote :

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

jazzynico (jazzynico) wrote :

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.

su_v (suv-lp) on 2014-11-06
Changed in inkscape:
assignee: Felipe "Juca" Sanches (felipe-sanches) → nobody
milestone: 0.91 → none
su_v (suv-lp) on 2015-02-06
Changed in inkscape:
milestone: none → 0.92
su_v (suv-lp) on 2015-05-25
summary: - feimage freezes inkscape if filtered object is the same as referenced
+ feimage crashes inkscape if filtered object is the same as referenced
object
summary: - feimage crashes inkscape if filtered object is the same as referenced
+ feImage crashes inkscape if filtered object is the same as referenced
object
Kakurady Drakenar (kakurady) wrote :

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?

Mc (mc...) wrote :

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 ).

Jabiertxof (jabiertxof) on 2016-07-19
Changed in inkscape:
assignee: nobody → Jabiertxof (jabiertxof)
Jabiertxof (jabiertxof) wrote :

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.

Jabiertxof (jabiertxof) wrote :

Also work on groups in the same way.

Mc (mc...) wrote :

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

Jabiertxof (jabiertxof) wrote :

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

Changed in inkscape:
assignee: Jabiertxof (jabiertxof) → nobody
jazzynico (jazzynico) on 2017-01-04
Changed in inkscape:
milestone: 0.92 → 0.93
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