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
librsvg 2.40.12 crashes rendering SVGs with filters
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
2.40.x
Other Linux
: Normal critical
: ---
Assigned To: librsvg maintainers
librsvg maintainers
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:
  • #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