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 340963 - should restrict svg dimensions to something reasonable
should restrict svg dimensions to something reasonable
Status: RESOLVED OBSOLETE
Product: eog
Classification: Core
Component: image viewer
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 407478 407495 656798 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-07 22:22 UTC by Sebastien Bacher
Modified: 2021-06-19 08:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
scale really huge images to fit on the screen (1.27 KB, patch)
2006-12-12 15:37 UTC, jacob berkman
needs-work Details | Review

Description Sebastien Bacher 2006-05-07 22:22:20 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"
Comment 1 jacob berkman 2006-12-12 15:37:34 UTC
Created attachment 78210 [details] [review]
scale really huge images to fit on the screen
Comment 2 Felix Riemann 2007-01-03 19:50:38 UTC
(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?).
Comment 3 Claudio Saavedra 2007-02-14 00:40:25 UTC
*** Bug 407495 has been marked as a duplicate of this bug. ***
Comment 4 Claudio Saavedra 2007-02-14 00:40:42 UTC
*** Bug 407478 has been marked as a duplicate of this bug. ***
Comment 5 Vytas 2007-10-07 23:26:38 UTC
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.
Comment 6 Andreas Moog 2008-09-07 16:06:35 UTC
Is there any news on this issue? Thanks.
Comment 7 Felix Riemann 2012-01-18 11:28:05 UTC
*** Bug 656798 has been marked as a duplicate of this bug. ***
Comment 8 nodiscc 2012-07-28 14:12:04 UTC
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.
Comment 9 Tobias Mueller 2012-11-19 21:07:33 UTC
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!
Comment 10 Robert Roth 2012-11-20 09:53:01 UTC
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.

Thread 3038772032 (LWP 6305)

  • #0 ??
    from /usr/lib/i386-linux-gnu/librsvg-2.so.2
  • #1 rsvg_handle_get_pixbuf_sub
    from /usr/lib/i386-linux-gnu/librsvg-2.so.2
  • #2 rsvg_handle_get_pixbuf
    from /usr/lib/i386-linux-gnu/librsvg-2.so.2
  • #3 eog_image_load
  • #4 ??
  • #5 eog_job_run
  • #6 ??
  • #7 ??
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #8 start_thread
    from /lib/i386-linux-gnu/libpthread.so.0
  • #9 clone
    from /lib/i386-linux-gnu/libc.so.6



[1] http://librarian.launchpad.net/2437909/crash.svg
Comment 11 Christopher M. Penalver 2014-12-10 08:12:53 UTC
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
Comment 12 André Klapper 2021-06-19 08:47:27 UTC
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.