Page MenuHomePhabricator

Jessie rsvg/cairo can't render specific SVG file on Commons
Closed, ResolvedPublic

Description

The error:
An user on Spanish Wikipedia reports that he can't see a map in some article: https://es.wikipedia.org/wiki/Condado_de_Armstrong_(Texas) (the file is https://commons.wikimedia.org/wiki/File:Map_of_Texas_highlighting_Armstrong_County.svg).

The server answers a HTTP 429 code

Steps to reproduce:

  • Open the article on any language and device (mobile or desktop) - even on Commons
  • Wait for it

Actual result

  • See the error on the map

Expected result:

  • A map pointing the place.

screenshot-es.wikipedia.org-2017-07-13-16-02-18.png (567×294 px, 137 KB)

Event Timeline

So, error code 429 is Too Many Requests, generally used by ratelimiters. In this case, it seems that thumbor (our internal service that renders thumbnails of images) issues a 429 because the SVG is failing to render (it might be invalid SVG in some sense, or at least making our SVG parsing tools explode). Making this more user-friendly is discussed in T169683

I don't see (yet) how this is SRE territory?

HTTP 429 sounded like T170109 but this file does NOT start with <svg:svg. Maybe T163610 or some other issue.

Restricted Application removed a subscriber: Kizule. · View Herald TranscriptJul 14 2017, 9:23 AM
Aklapper renamed this task from HTTP 429 on image on Commons to HTTP 429 on thumbnail images for specific SVG file on Commons.Jul 14 2017, 9:23 AM

These county maps show up disproportionately in the failing thumbnail logs. The issue with them predates Thumbor, because it's a problem at the rsvg-convert level (which is also what Mediawiki uses). They make rsvg-convert segfault:

gilles@thumbor1001:~$ rsvg-convert --version
rsvg-convert version 2.40.16
gilles@thumbor1001:~$ rsvg-convert Map_of_Texas_highlighting_Armstrong_County.svg > foo.png
Segmentation fault

Surprisingly, though, I've just noticed that rsvg-convert handles them correctly on OS X:

MBP-de-Gilles:Downloads gillesdubuc$ rsvg-convert --version
rsvg-convert version 2.40.17
MBP-de-Gilles:Downloads gillesdubuc$ rsvg-convert Map_of_Texas_highlighting_Armstrong_County.svg > foo.png
MBP-de-Gilles:Downloads gillesdubuc$

Maybe it has to do with our custom build/package of rsvg-convert? Or a bugfix in 2.40.17?

gilles@thumbor1001:~$ dpkg -l librsvg2-bin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                               Version                Architecture           Description
+++-==================================-======================-======================-=========================================================================
ii  librsvg2-bin                       2.40.16-1+wmf1         amd64                  command-line and graphical viewers for SVG files
Gilles changed the task status from Open to Stalled.Jul 17 2017, 1:17 PM
Gilles triaged this task as Medium priority.
Gilles added a project: Performance-Team.

Trying a stretch machine on labs, which runs 2.40.16-1+b1, works fine. And the source for it looks identical to 2.40.16-1+wmf1

I think this is looking like a Linux issue in the environment more than a problem with rsvg-convert itself.

Trying on a labs Jessie machine (which gets the WMF version of the package), it segfaults. I'm starting to think that this is an issue with rsvg-convert on Jessie.

Looking at the backtrace I'm pretty it's a bug in Cairo and only exposed by rsvg-convert. That would explain why it's not reproducible on stretch, but on jessie. We can't easily backport cairo, though, it's has cross-dependencies to other Gnome libs. But this will be fixed when we migrate the app servers to stretch.

The Thumbor servers, in this case, but yeah. I guess I can file a task for that...

Which exact Cairo versions are involved? Could the stacktrace be shared? (If that's not a waste of time if T170817 isn't too far away?)
Cannot reproduce either with librsvg 2.40.17 and cairo 1.14.10 on Fedora 26.

Backtrace is here: It crashes accessing right->deferred.other in active_edges(), but the code in 1.14.10 from stretch is almost the same, so it's rather caused by any of the reverse deps in the Gnome stack. I don't know the specific plans for T170817, but I'm all for it and willing to help as needed, rather than spending time to track/fix this in the current setup (as it will be quite time-consuming)

#0  active_edges (polygon=0x7ffd44566d60, top=1617, left=0x7f7d2f0c9250) at ../../../../src/cairo-polygon-i
ntersect.c:1235
#1  intersection_sweep (polygon=0x7ffd44566d60, num_events=<optimized out>, start_events=<optimized out>) a
t ../../../../src/cairo-polygon-intersect.c:1271
#2  _cairo_polygon_intersect (a=a@entry=0x7ffd44566d60, winding_a=winding_a@entry=0, b=b@entry=0x7ffd445669
10, winding_b=<optimized out>)
    at ../../../../src/cairo-polygon-intersect.c:1466
#3  0x00007f7d34a0e10a in clip_and_composite_polygon (compositor=compositor@entry=0x7f7d34cb7140 <spans>, e
xtents=extents@entry=0x7ffd445671b0,
    polygon=polygon@entry=0x7ffd44566d60, fill_rule=CAIRO_FILL_RULE_WINDING, antialias=antialias@entry=CAIR
O_ANTIALIAS_DEFAULT)
    at ../../../../src/cairo-spans-compositor.c:946
#4  0x00007f7d34a0ecba in _cairo_spans_compositor_stroke (_compositor=0x7f7d34cb7140 <spans>, extents=0x7ff
d445671b0, path=<optimized out>, style=0x7ffd445675c0,
    ctm=0x7ffd445675f0, ctm_inverse=0x7ffd44567620, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIA
S_DEFAULT) at ../../../../src/cairo-spans-compositor.c:1083
#5  0x00007f7d349c9daf in _cairo_compositor_stroke (compositor=0x7f7d34cb7140 <spans>, surface=0x3f, op=CAI
RO_OPERATOR_SOURCE, source=0x1, path=0x23b4c48,
    style=0x7ffd445675c0, ctm=0x7ffd445675f0, ctm_inverse=0x7ffd44567620, tolerance=0.10000000000000001, an
tialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x1fe39c0)
    at ../../../../src/cairo-compositor.c:157
#6  0x00007f7d349db162 in _cairo_image_surface_stroke (abstract_surface=<optimized out>, op=<optimized out>, source=<optimized out>, path=<optimized out>,
    style=<optimized out>, ctm=<optimized out>, ctm_inverse=0x7ffd44567620, tolerance=<optimized out>, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x1fe39c0)
    at ../../../../src/cairo-image-surface.c:964
#7  0x00007f7d34a12056 in _cairo_surface_stroke (surface=0x1fe9ec0, op=CAIRO_OPERATOR_OVER, source=0x7ffd44567650, path=0x23b4c48, stroke_style=0x7ffd445675c0,
    ctm=0x7ffd445675f0, ctm_inverse=0x7ffd44567620, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x1fe39c0)
    at ../../../../src/cairo-surface.c:2270
#8  0x00007f7d349d1c62 in _cairo_gstate_stroke (gstate=0x1fe3a10, path=path@entry=0x23b4c48) at ../../../../src/cairo-gstate.c:1194
#9  0x00007f7d349cb719 in _cairo_default_context_stroke (abstract_cr=0x23b48e0) at ../../../../src/cairo-default-context.c:1010
#10 0x00007f7d349c4745 in INT_cairo_stroke (cr=0x7040) at ../../../../src/cairo.c:2150
Gilles renamed this task from HTTP 429 on thumbnail images for specific SVG file on Commons to Jessie rsvg/cairo can't render specific SVG file on Commons.Sep 8 2017, 7:13 AM
Gilles moved this task from Backlog to Radar on the Thumbor board.
MoritzMuehlenhoff claimed this task.

The new 2.4.18 backport has been rolled out to all Thumbor hosts and image scalers.

The upgrade hasn't fixed the problem. It seems like converting the file without options works, but not with the options we typically use:

gilles@thumbor1001:~$ rsvg-convert Map_of_Texas_highlighting_Armstrong_County.svg > foo.png
gilles@thumbor1001:~$ rsvg-convert Map_of_Texas_highlighting_Armstrong_County.svg -u -f png -w 100 > foo.png
Segmentation fault

It's specifically resizing it takes issue with.

The upgrade hasn't fixed the problem. It seems like converting the file without options works, but not with the options we typically use:

gilles@thumbor1001:~$ rsvg-convert Map_of_Texas_highlighting_Armstrong_County.svg > foo.png
gilles@thumbor1001:~$ rsvg-convert Map_of_Texas_highlighting_Armstrong_County.svg -u -f png -w 100 > foo.png
Segmentation fault

Same call works fine on stretch, though.

Probably something in the Cairo libraries? That's where you located the issue last time.

Probably something in the Cairo libraries? That's where you located the issue last time.

Yeah, let's not go down this rabbit hole, Cairo has too many cross-dependencies with other Gnome libs. This bug will be fixed when we upgrade thumbor* to stretch.

Aklapper changed the task status from Open to Stalled.Nov 2 2017, 1:18 PM

Setting task status to stalled as this is blocked on fixing T170817: Upgrade Thumbor servers to Stretch.

jijiki claimed this task.
jijiki subscribed.

Looks like this file is ok after upgrading to stretch