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 710310 - librsvg can't handle big files anymore
librsvg can't handle big files anymore
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
3.12.1
: 719895 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-16 17:28 UTC by Olivier Galibert
Modified: 2014-06-18 18:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Added huge flag for large svg processing (2.31 KB, patch)
2013-12-10 09:39 UTC, ICT
needs-work Details | Review
Same as last patch suggestion but with comment for documentation (2.73 KB, patch)
2013-12-10 11:23 UTC, ICT
needs-work Details | Review

Description Olivier Galibert 2013-10-16 17:28:55 UTC
libxml2 now requires the XML_PARSE_HUGE option to handle big files.  There is currently no way in librsvg to pass this option down, with the result that large files can't be handled.

With a gross hack to pass the option everything works perfectly well, there is no underlying library limitation.

  OG.

PS: example of large svg file: http://dspnet.fr/~galibert/m68k/layers.7z
Comment 1 Christian Persch 2013-10-16 17:40:41 UTC
Which limit does it hit, the dict size limit of 10000000 ?

I don't think just adding XML_PARSE_HUGE is right, since that'll open up librsvg to the problem that made libxml introduce these limits in the first place…
Comment 2 Olivier Galibert 2013-10-16 18:16:13 UTC
rvsg parsing failure Error domain 1 code 1 on line 866723 column 1 of data: internal error: Huge input lookup

It probably is the 10e6 dict size limit.

  OG.
Comment 3 Christian Persch 2013-12-05 17:21:59 UTC
*** Bug 719895 has been marked as a duplicate of this bug. ***
Comment 4 Arjen Nienhuis 2013-12-06 09:08:39 UTC
(In reply to comment #1)
> Which limit does it hit, the dict size limit of 10000000 ?
> 
> I don't think just adding XML_PARSE_HUGE is right, since that'll open up
> librsvg to the problem that made libxml introduce these limits in the first
> place…

What about adding a flag to RsvgHandleFlags. Then programs can opt-in when it's safe.

RSVG_HANDLE_FLAGS_HUGE = 1
Comment 5 Christian Persch 2013-12-06 21:38:01 UTC
Yes, I'd accept a patch that adds the flag and corresponding cmdline options for rsvg-convert and rsvg-view.
Comment 6 ICT 2013-12-10 09:39:50 UTC
Created attachment 263898 [details] [review]
Added huge flag for large svg processing

patch suggested by a.nienhuis
Comment 7 Christian Persch 2013-12-10 10:20:44 UTC
Comment on attachment 263898 [details] [review]
Added huge flag for large svg processing

Need to add gtk-doc comment to document the RsvgHandleFlags enum, now that it has non-0 flags.
Comment 8 ICT 2013-12-10 11:23:18 UTC
Created attachment 263909 [details] [review]
Same as last patch suggestion but with comment for documentation

Same as last patch suggestion but with comment for documentation generation as described by gtk-doc
Comment 9 Arjen Nienhuis 2014-01-07 14:17:04 UTC
Can someone take a look at this patch?

Is there anything else we can do?
Comment 10 Matthias Clasen 2014-03-20 23:44:15 UTC
patch looks good to me, fwiw
Comment 11 Christian Persch 2014-03-21 00:17:43 UTC
Comment on attachment 263909 [details] [review]
Same as last patch suggestion but with comment for documentation

+* @RSVG_HANDLE_FLAGS_HUGE: Allows for xml_data over 10 MB to be read

I don't like the name of the flag, and the docs isn't quite correct, and also not verbose enough. And the docs should also mention the security implications for using this flag.
Comment 12 ICT 2014-03-21 09:14:49 UTC
The HUGE naming is based upon the underlying flag that is invoked using this one (RSVG_HANDLE_FLAGS_HUGE invokes XML_PARSE_HUGE from libxml2). Thus the name is as logical as it can get I think. 

As for the changes in documentation I'll see what I can do.