A more straightforward example is https://commons.wikimedia.org/wiki/File:SVG_edge_case_-_zero_scale_gradient.svg
It's a divide-by-zero type of situation, in which the SVG Checker stops rendering and WikiMedia's renderer falls back to a default.

Thanks for reporting.

Wikimedia servers have been updated to librsvg 2.40.16

Per T170810 I think production is actually on 2.40.18.

According to the change log, 2.40.18 fixed CVE-2017-11464 ("A SIGFPE is raised in the function box_blur_line... because of incorrect protection against division by zero."). I don't have different versions of rsvg available to test, but I imagine that it's the difference between 2.40.16 (Toolforge) and 2.40.18 (production) that is therefore causing the issue.

I am not sure whether the easiest fix is for 2.40.18 to be installed on Kubernetes (T151656) or on Stretch (no task filed).

In T218828#5068833, @Jarry1250 wrote:

Thanks for reporting.

Wikimedia servers have been updated to librsvg 2.40.16

Per T170810 I think production is actually on 2.40.18.

The "librsvg2-2" binary package versions are nowadays:

2.40.16-1+b1 5 , 2.40.21-0+deb9u1 2155 , 2.44.10-2.1 580

that is 5 servers on the first version, 2155 on the second and 580 on the third

The image looks identical since a while.

In T218828#7022133, @Dzahn wrote:

The "librsvg2-2" binary package versions are nowadays:

2.40.16-1+b1 5 , 2.40.21-0+deb9u1 2155 , 2.44.10-2.1 580

that is 5 servers on the first version, 2155 on the second and 580 on the third

It reminds me on a discussion where different users saw different rendering-results. A not reproducible result is imho much worse than a reproducible bug.

@Dzahn

• Why do the version not agree with https://apt-browser.toolforge.org/stretch-wikimedia/component/thumbor/ ?
• Do the reported librsvg-version relate to production or to toolforge or both?
• Does it mean different servers depending on the location render differently, and show different librsvg-bugs?

@JoKalliauer To check the production APT repo check out https://apt.wikimedia.org/wikimedia/

So far I know nothing about apt-browser.toolforge.org and its relation to that.

When I reported the versions above it related only to production.

Yes, I think that's what it means. Toolforge and production are separated almost entirely.

@JoKalliauer Here is info from one of the _production_ thumbor servers, thumbor2003.codfw.wmnet:

[thumbor2003:~] $ lsb_release -c
Codename:	stretch


[thumbor2003:~] $ dpkg -l | grep svg
ii  librsvg2-2:amd64                      2.40.21-0+deb9u1                       amd64        SAX-based renderer library for SVG files (runtime)
ii  librsvg2-bin                          2.40.21-0+deb9u1                       amd64        command-line and graphical viewers for SVG files
ii  librsvg2-common:amd64                 2.40.21-0+deb9u1                       amd64        SAX-based renderer library for SVG files (extra runtime)

[thumbor2003:~] $ apt-cache policy librsvg2-bin
librsvg2-bin:
  Installed: 2.40.21-0+deb9u1
  Candidate: 2.40.21-0+deb9u1
  Version table:
 *** 2.40.21-0+deb9u1 500
        500 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.40.16-1+b1 500
        500 http://mirrors.wikimedia.org/debian stretch/main amd64 Packages

https://mirrors.wikimedia.org/debian/dists/stretch/main/binary-amd64/

https://mirrors.wikimedia.org/debian/pool/main/libr/librsvg/

@JoKalliauer

thumbor* and mwmaint* servers in production have: 2.40.21-0+deb9u1

regular mediawiki appservers and all other servers production have: 2.44.10-2.1

What toolforge has please check with wmcs or with your own user.

Toolforge likely has several different versions running on different hosts, but the specific container that svgcheck.toolforge.org is currently running in looks like this:

[taavi@tools-sgebastion-08 ~] $ kubectl exec -it -n tool-svgcheck svgcheck-69fc5956dd-p7h7t --as admin --as-group system:masters -- /bin/bash
tools.svgcheck@svgcheck-69fc5956dd-p7h7t:~$ apt-cache policy librsvg2-bin
librsvg2-bin:
  Installed: 2.40.21-0+deb9u1
  Candidate: 2.40.21-0+deb9u1
  Version table:
 *** 2.40.21-0+deb9u1 100
        100 /var/lib/dpkg/status
tools.svgcheck@svgcheck-69fc5956dd-p7h7t:~$ dpkg -l | grep svg
ii  librsvg2-2:amd64              2.40.21-0+deb9u1                                            amd64        SAX-based renderer library for SVG files (runtime)
ii  librsvg2-bin                  2.40.21-0+deb9u1                                            amd64        command-line and graphical viewers for SVG files
ii  librsvg2-common:amd64         2.40.21-0+deb9u1                                            amd64        SAX-based renderer library for SVG files (extra runtime)

So I think this issue can be closed as resolved?

You are the author, so I think if you are satisfied with the explanation, then yes it can be closed.