EOG crashes on SVG images created with OpenOffice.org Draw

Bug #42629 reported by Vytas on 2006-05-02
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Eye of GNOME
Fix Released
eog (Ubuntu)

Bug Description

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

Program received signal SIGABRT, Aborted.
[Switching to Thread -1239532624 (LWP 11914)]
0xffffe410 in __kernel_vsyscall ()

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.

Sebastien Bacher (seb128) wrote :

Thanks for your bug. I've forwarded that upstream has a librsvg issue: http://bugzilla.gnome.org/show_bug.cgi?id=340440

Changed in eog:
assignee: nobody → desktop-bugs
status: Unconfirmed → Confirmed
Sebastien Bacher (seb128) wrote :

upstream pointed that's not an only issue, I've forwarded that to eog then: http://bugzilla.gnome.org/show_bug.cgi?id=340963

Changed in eog:
status: Unconfirmed → Confirmed
Obsidience (gabe-anguiano) wrote :

I just got a near lockup opening an SVG file created in inkscape using EOG on Gutsy. The file was not very large but the eog processed quickly consumed 1GB of memory which caused severe stutters (no lockups). Looks like a memory leak, I'm attaching the image I was trying to open.

Vytas (vytas) wrote :

it is not a memory leak as such; see my comments in the description, or comments in the gnome-bugzilla. Your example is just another illustration of the bug.

librsvg (the library that draws svg image) can render it to any size, because it's vector graphics. EOG currently tries the pixel size that is provided in SVG description. In your example, it is 18k x 18k px. So, EOG asks "please render me this SVG to a 18kx18k 32bit RBG image, that is a 1.207 GiB bitmap. So librsvg did, and EOG displayed the result on your screen.

See the comments in gnome bugzilla for current situation and possible solutions.

Changed in eog:
status: Confirmed → Triaged
Changed in librsvg:
status: Confirmed → Fix Released
Andreas Moog (ampelbein) wrote :

This bug has been unchanged for a while. Is this still an issue for you?

Changed in eog:
status: Triaged → Incomplete
Leon van der Ree (lvanderree) wrote :

It is for me,

I think I can also provide an example if you like

Andreas Moog (ampelbein) wrote :

Thanks for the update. I asked upstream if there is any news, I'll post whatever response I get.

Changed in eog:
status: Incomplete → Triaged
Chris Cheney (ccheney) on 2009-01-26
Changed in openoffice:
status: New → Invalid
Changed in librsvg:
importance: Unknown → Medium
Changed in eog:
importance: Unknown → Medium
ubeagle (fun-stuff) wrote :

Just a medium bug?
I just experienced this trying to open an A4 sized exported OOo drawing. Only could stop my computer hanging itself up in by switching to a text console and killing the process (took me a couple of minutes due to the lag). System monitor applet showed that my 4GB (and then the swap partition on my hard drive ;-)) were in 100% use all the time.

Robert Roth (evfool) wrote :

I agree that the importance of this issue should be raised. I also tried to open the attached crash.svg, it opened in less then a second in chromium, and with eog the system stopped responding, the only solution was to log out with Alt+PrtScr+K and then log back in.

Taras Halturin (halturin) wrote :

another one example of SVG-file of death :)

Using latest 32-bit Ubuntu 10.10, this still causes eog and even GIMP to consume massive amounts of memory, the system becomes completely unresponsive and at some time just freezes. Hard reboot is required after this. The only program capable of opening this file from Draw seems to be Inkscape.

pipe (pipatron) wrote :

Not only images from OpenOffice are to blame here. I just recently ran into this bug by creating an overhead layout of my apartment in Inkscape. I set the page size to 10 x 10 metres, and the resulting image, though frugal in content, instantly consumes gigabytes of memory when I try to display it or open it in certain file browser dialogues.
The rapid memory usage increase will lock up pretty much everything as far as I can see, I can't switch to the text console or do anything with the computer except a cold reboot. This is of course unacceptable behaviour, and you can shuffle the blame around from librsvg to eog, from eog to linux opportunistic memory allocator, to the svg specification, but that doesn't fix the very real problem.

I ran into this one with some SVG images generated by graphviz from dot files.

My problem was even more extreme ; the entire X server crashed, taking my session and all my open applications with it. IMHO that makes it more than a minor bug - anything that can crash your X server can cause you to lose significant amounts of work.

This happens reliably on both SVG and PNG images generated by the dot utility from the same file. The image is 4344x11893 pixels.

The SVG will open harmlessly in Inkscape. The PNG opens harmlessly in GIMP. The thumbnail generator in nautilus creates a thumbnail for both without causing problems.

Therefore I'm inclined to blame eog for the problem. Note especially that the problem happens with PNG and not just SVG.

I've attached an SVG file that crashes the entire X server when opened in eog (but not when opened in Inkscape).

This doesn't happen on my home desktop with a big beefy nvidia card, just on "productivity" machines with lesser graphics cards.

Changed in eog:
status: Confirmed → Incomplete
Changed in eog:
status: Incomplete → Expired
Changed in eog:
status: Expired → Confirmed

Vytas, a crash is not reproducible in Trusty with the document you attached.

Please feel free to report any future bugs you may find.

Helpful bug reporting tips:

lsb_release -rd && apt-cache policy eog
Description: Ubuntu 14.04.1 LTS
Release: 14.04
  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

Changed in eog (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.