Bug 759084 – librsvg 2.40.12 crashes rendering SVGs with filters

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 759084 - librsvg 2.40.12 crashes rendering SVGs with filters


Summary:	librsvg 2.40.12 crashes rendering SVGs with filters


Status:	RESOLVED FIXED

Product:	librsvg
Classification:	Core
Component:	general
Version:	2.40.x
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	---
Assigned To:	librsvg maintainers
QA Contact:	librsvg maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2015-12-06 10:23 UTC by Jan Alexander Steffens (heftig)
Modified:	2016-01-29 15:36 UTC

See Also:
GNOME target:	---
GNOME version:	3.17/3.18

Attachments
Attempted fix; did not work. (2.71 KB, patch) 2015-12-06 10:23 UTC, Jan Alexander Steffens (heftig)	none	Details \| Review

Description Jan Alexander Steffens (heftig) 2015-12-06 10:23:26 UTC

Created attachment 316833 [details] [review]
Attempted fix; did not work.

librsvg crashes when rendering SVGs with filters, as used by at least Cinnamon and the preferences window of the shell extension "Dash to dock". I've reproduced it with the latter.

The extension renders this SVG:
https://raw.githubusercontent.com/micheleg/dash-to-dock/master/media/logo.svg

Upstream bug: https://bugs.archlinux.org/task/47245

Stack trace:

+ Trace 235787

#0 raise
from /usr/lib/libc.so.6
#1 abort
from /usr/lib/libc.so.6
#2 __assert_fail_base
from /usr/lib/libc.so.6
#3 __assert_fail
from /usr/lib/libc.so.6
#4 cairo_surface_reference
from /usr/lib/libcairo.so.2
#5 rsvg_filter_render
at rsvg-filter.c line 504
#6 rsvg_cairo_pop_render_stack
at rsvg-cairo-draw.c line 842
#7 rsvg_cairo_pop_discrete_layer
at rsvg-cairo-draw.c line 896
#8 rsvg_node_draw
at rsvg-structure.c line 54
#9 _rsvg_node_draw_children
at rsvg-structure.c line 70
#10 rsvg_node_draw
at rsvg-structure.c line 54
#11 _rsvg_node_draw_children
at rsvg-structure.c line 70
#12 rsvg_node_draw
at rsvg-structure.c line 54
#13 _rsvg_node_draw_children
at rsvg-structure.c line 70
#14 rsvg_node_draw
at rsvg-structure.c line 54
#15 rsvg_node_svg_draw
at rsvg-structure.c line 309
#16 rsvg_node_draw
at rsvg-structure.c line 54
#17 rsvg_handle_render_cairo_sub
at rsvg-cairo-render.c line 224
#18 rsvg_handle_get_pixbuf_sub
at rsvg.c line 90
#19 rsvg_handle_get_pixbuf
at rsvg.c line 119
#20 gdk_pixbuf__svg_image_stop_load
at io-svg.c line 158
#21 generic_load_incrementally
at gdk-pixbuf-io.c line 1016
#22 gdk_pixbuf_new_from_file
at gdk-pixbuf-io.c line 1103
#23 gtk_builder_value_from_string_type
at gtkbuilder.c line 2068
#24 gtk_builder_value_from_string
at gtkbuilder.c line 1815
#25 gtk_builder_get_parameters
at gtkbuilder.c line 519
#26 _gtk_builder_construct
at gtkbuilder.c line 660
#27 builder_construct
at gtkbuilderparser.c line 139
#28 end_element
at gtkbuilderparser.c line 1073
#29 emit_end_element
at gmarkup.c line 1077
#30 g_markup_parse_context_parse
at gmarkup.c line 1619
#31 _gtk_builder_parser_parse_buffer
at gtkbuilderparser.c line 1259
#32 gtk_builder_add_from_file
at gtkbuilder.c line 1029



Apparently there are destroyed surfaces on the render->surfaces_stack.

However, there seem to be deeper issues as simply adding references for the stack (as done by the attached patch) results in bad rendering — a solid blue output.

Attempting to open logo.svg in eog crashes as well.

Opening logo.svg with rsvg-view-3 does not crash, but it still shows an error:

(rsvg-view-3:19324): librsvg-CRITICAL **: rsvg_filter_render: assertion 'cairo_surface_get_type (source) == CAIRO_SURFACE_TYPE_IMAGE' failed

Comment 1 Jan Alexander Steffens (heftig) 2015-12-06 10:24:04 UTC

Er, that should have been "Downstream bug:", of course.

Comment 2 Michael Biebl 2015-12-10 23:36:30 UTC

This is a regression in 2.40.12, fwiw. With 2.40.11 the logo.svg is processed properly.

Comment 3 Michael Biebl 2015-12-16 01:40:07 UTC

git bisect shows the following as the (first) faulty commit:

commit 9fc56102ca1861e3868fd6dcbcc3cc0f3c240f3e
Author: Benjamin Otte <otte@redhat.com>
Date:   Wed Oct 7 10:37:22 2015 +0200

    state: Resolve filters lazily
    
    We're almost there resolving everything lazily...



Benjamin, would be great if you can have a look

Comment 4 Jan Alexander Steffens (heftig) 2016-01-08 23:39:27 UTC

The extension updated the logo to avoid triggering this bug. Here's the old logo which still causes crashes:

https://raw.githubusercontent.com/micheleg/dash-to-dock/370f6e07c2dae6aa527b9054a154ae3b0e619ce7/media/logo.svg

(2.40.13 is not fixed yet.)

Comment 5 Benjamin Otte (Company) 2016-01-29 12:17:32 UTC

commit d937c691678803ceda6be701587d997ccd03a1da
Author: Benjamin Otte <otte@redhat.com>
Date:   Fri Jan 29 12:49:55 2016 +0100

    Don't crash when filters don't exist
        
    We put a new surface on the stack if a filter existed by name but we
    didn't pop it if the name didn't resolve to a real filter.
                    
    New test: crash/bug759084.svg

Comment 6 Michael Biebl 2016-01-29 15:36:21 UTC

fwiw, I can confirm it fixes the issues I was seeing.

Thanks Benjamin