GNOME Bugzilla – Bug 340963
should restrict svg dimensions to something reasonable
Last modified: 2021-06-19 08:47:27 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/eog/+bug/42629 "EOG crashes on SVG images created with OpenOffice.org Draw. As I understand, the problem is that OpenOffice.org SVG export plugin uses plain huge integer dimensions, not centimeters, inches or something relavant. EOG just fails to allocate memory for an "über"-sized image then. I guess that from the following output: GLib-ERROR **: gmem.c:154: failed to allocate 2412898400 bytes aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1239532624 (LWP 11914)] 0xffffe410 in __kernel_vsyscall () (gdb) Personally Im not sure which side requires fixing, maybe both. OpeOffice should export in sane dimensions, and EOG should automatically reduce images or do something but not crash. Both Firefox and Inkscape load the image correctly. http://librarian.launchpad.net/2437909/crash.svg Crashes with SIGABRT" I've forwarded the issue to librsvg first which is bug #340440, comment from the maintainer: "When the SVG provides no size (and the size can't be computed by finding the image's bounding box), we have no choice but to assume that the viewbox represents units in user-space. In this case, that's 21590x27940 pixels. We dutifully report the image's width&height in pixels, as well as the X&Y DPIs, as required by the spec. The calling application then has a duty to "sanitize" those values. In EOG's case, that might mean restricting the image's size to the size of the visible window. http://www.w3.org/TR/SVG/coords.html#Introduction"
Created attachment 78210 [details] [review] scale really huge images to fit on the screen
(In reply to comment #1) > Created an attachment (id=78210) [edit] > scale really huge images to fit on the screen > Although the patch works around the problem, it is not fully correct. The problem is that every picture which is by a certain factor larger than my desktop is scaled down. This makes every image transformation except lossless JPEG tranform useless as they are applied to the scaled image. A picture taken with 7 megapixel camera could trigger that on a 1024x768 desktop. I am not sure if it is sufficient to set a different factor or if we should apply this only to SVG images (or both?).
*** Bug 407495 has been marked as a duplicate of this bug. ***
*** Bug 407478 has been marked as a duplicate of this bug. ***
The patch is incorrect even for SVG images. For example, SVG may contain small details that user may want to zoom and inspect, that is what zoom function is for. My suggestion is - render SVG images on the fly, to the window size. When window is resized, render new bitmap from SVG to the new window size in the background, and while it is working, produce the previous bitmap scaled [with no filters for max speed] to the new size for coarse preview.
Is there any news on this issue? Thanks.
*** Bug 656798 has been marked as a duplicate of this bug. ***
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it. Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Reopening, as I can reproduce this using EOG 3.6.0. and the crash.svg file from the description [1]. gdb session running eog with the given file gives the following: Starting program: /usr/bin/eog eog crash.svg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [New Thread 0xb65b9b40 (LWP 6303)] [New Thread 0xb5bffb40 (LWP 6304)] [New Thread 0xb51ffb40 (LWP 6305)] [New Thread 0xae832b40 (LWP 6306)] (eog:6299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed (eog:6299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion `GDK_IS_PIXBUF (pixbuf)' failed (eog:6299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels: assertion `GDK_IS_PIXBUF (pixbuf)' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 231196
Thread 3038772032 (LWP 6305)
[1] http://librarian.launchpad.net/2437909/crash.svg
Attempting to test to this from duplicate bug https://bugzilla.gnome.org/show_bug.cgi?id=656798 failed, as eog notes: Could not load image 'CodigoGray4Bits2.svg'. Image loading failed. Is SVG 1.1 still supported in eog, or would this be a bug in this version of eog? lsb_release -rd && apt-cache policy eog Description: Ubuntu 14.04.1 LTS Release: 14.04 eog: Installed: 3.10.2-0ubuntu5 Candidate: 3.10.2-0ubuntu5 Version table: *** 3.10.2-0ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.