There are empty/broken icons with empty paths (causing latest librsvg to crash)
nezumisama opened this issue · 6 comments
The following svg files:
scalable/real_icons/actions/edit-select-all.svg
scalable/real_icons/actions/mail-mark-read.svg
scalable/real_icons/apps/dropboxstatus-blank.svg
scalable/real_icons/apps/nm-signal-00.svg
scalable/real_icons/status/nm-signal-0.svg
scalable/real_icons/status/notification-network-wireless-none.svg
all cause librsvg (versions 2.41.0+, 2.42.0 is the latest) to crash. I noticed this today after update. The bug in librsvg is reported here: https://gitlab.gnome.org/GNOME/librsvg/issues/187
The crash in turn causes Gtk applications that want to display the affected icons to crash (inkscape in my case).
You can obtain this list if you have rsvg-convert and the affected librsvg by doing:
for i in `find . -name '*.svg' -type f`; do rsvg-convert $i -o /dev/null &> /dev/null || echo $i; done
All those files are in fact identical (same md5), and they contain an empty path object (<path d="" id="path-main"/>), crashing librsvg.
It could be that the python script is supposed to fix those files, but this didn't happen to me despite setting a custom color and alts.
If you don't intend to supply those icons, it would be best to remove them and their symlinks:
# real files
scalable/real_icons/status/notification-network-wireless-none.svg
scalable/real_icons/status/nm-signal-0.svg
scalable/real_icons/apps/nm-signal-00.svg
scalable/real_icons/apps/dropboxstatus-blank.svg
scalable/real_icons/actions/mail-mark-read.svg
scalable/real_icons/actions/edit-select-all.svg
# symlinks
scalable/status/notification-network-wireless-none.svg
scalable/status/nm-signal-0.svg
scalable/apps/nm-signal-00.svg
scalable/apps/dropboxstatus-blank.svg
scalable/actions/stock_mail-open.svg
scalable/actions/stock_mail-open-multiple.svg
scalable/actions/mail-mark-read.svg
scalable/actions/stock_select-all.svg
scalable/actions/gtk-select-all.svg
scalable/actions/edit-select-all.svg
Thanks for report, it was very helpful.
This icons are empty indeed (which make sense except edit-select-all may be). Not sure if I used some illegal svg constructions or it is librsvg bug. Lets wait for librsvg devs answer.
I made a temporary workaround anyway, it will allow use ACYLS with latest lib for now.
Seems that what breaks librsvg is the commination of linearGradient and a path linked via xlink, for which a fill makes no sense (since it's empty in your case; any path with zero area causes this error actually). However, the spec says "Note that the BNF allows the path ‘d’ attribute to be empty. This is not an error, instead it disables rendering of the path.", so the path can be empty. The library also works if I remove the gradient and/or not link to it, and the crash happens in a function associated with gradients. In either case, the icon doesn't represent any useful image, and older versions of librsvg just render an empty transparent image. I'd expect e.g. edit-select-all to show some symbol for selecting all items in a list, not an empty square.
Also, if you want an empty SVG icon, you can just do:
<svg width="48" height="48"/>
I confirmed this works for rsvg (including the version that crashes) yeilding a 48x48 bitmap filled with zero alpha. It also validates with the W3C validator.
Also, if you want an empty SVG icon, you can just do
Since all icons are processed automatically on recolor and filtering they should have consistent structure. Otherwise some tricky exceptions should be added to scripts. Previous version of lib was tolerant to my current structure so I'm waiting for librsvg devs reaction, may be this will be fixed on there end.
Also edit-select-all fixed (other icons are empty by design I believe). Massive icon base came from original project, so I can easily miss such flaws. Feel free to report.
I understand you got those icons form the original ACYL, and can't know about every such bug, and I appreciate the work you're doing in maintaining this set (which is really the only decent one in my books).
But I wonder if something could be done to avoid such problems in the future. I plan to investigate this when I get some free time. I'm guessing some tests could be added to sanity-check icons (Does any version of rsvg report some problem (or even crash)? Does the icon produce any non-trivial image (unless it's supposed to)? Etc.).
Bash script similar to one-liner you used for check rsvg messages can be added I think. Not sure about any deeper tests. All icons have standard structure (the drawing itself is literally single path) and there is no much place for errors. Filters are a bit different story, it may be pretty complex. But honestly I have a superficial understanding about SVG mechanic so I have no suggestions on topic.
In the end I'm ok with current situation when issues dealt as they are found manually, but any improvement are welcome.
The problem was fixed with librsvg 2.42.1, seems it's safe to close now.