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 710789 - on loading uncompressed 264MB TIF file eog crashes the whole user session
on loading uncompressed 264MB TIF file eog crashes the whole user session
Status: RESOLVED OBSOLETE
Product: eog
Classification: Core
Component: image viewer
3.10.x
Other Linux
: Normal critical
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-24 11:32 UTC by Christian Stadelmann
Modified: 2015-07-25 18:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this is everything journalctl displays related to this bug. (4.52 KB, application/octet-stream)
2013-10-28 19:36 UTC, Christian Stadelmann
Details

Description Christian Stadelmann 2013-10-24 11:32:48 UTC
Running eog 3.10.1 from Fedora 20 x86_64

Steps to reproduce:
1. Download the file DTK500.zip from http://www.vermessung.bayern.de/opendata (Bavarian Department of Geo Information; direct link: http://www.vermessung.bayern.de/opendata/doc,DTK500.html )
2. extract the file
3. open d500col.tif using eog
4. wait

What happens:
1. Gnome Desktop freezes (on a Dual Core machine)
2. Gnome Session crashes, killing all running user applications.

What should happen:
1. Eog should display the image as evince, gimp and other applications do
2. If Eog fails to display the image, it should not crash but fail gracefully(display some kind of error message)
3. If Eog crashes, it must not crash the gnome session
Comment 1 Felix Riemann 2013-10-26 12:51:19 UTC
What graphics card/driver do you use?

I tried with two different F20 machines (NVidia (binary driver)- and Intel-based) and both showed the map correctly without crashing.
Comment 2 Christian Stadelmann 2013-10-26 13:37:28 UTC
I have a Intel HD Graphics (from Core i5-650). Driver is xorg-x11-drv-intel 2.21.15 and a 3.11.5 or 3.11.6 kernel with i915 loaded.
Comment 3 Felix Riemann 2013-10-28 18:48:16 UTC
(In reply to comment #2)
> I have a Intel HD Graphics (from Core i5-650). Driver is xorg-x11-drv-intel
> 2.21.15 and a 3.11.5 or 3.11.6 kernel with i915 loaded.

Comes pretty close to my Intel-based setup, which is a i5-560M (with disabled nVidia Optimus). While it takes a noticable moment (~1-1.5 s) after loading the picture is eventually displayed without crashing.

Is there anything in the Xorg logs after such a crash?
Comment 4 Christian Stadelmann 2013-10-28 19:34:54 UTC
For me it takes a noticeable moment (~2…3s) to load the image, then freezes the UI for about 3…5 seconds and then crashes and restarts the X server

Since my abrt works again (some configuration issue I created) I uploaded a report generated by abrt: https://bugzilla.redhat.com/show_bug.cgi?id=1024092
The retrace is here: https://retrace.fedoraproject.org/faf/reports/bthash/c892c3292d002cc5382511901726ccd875202106/
Comment 5 Christian Stadelmann 2013-10-28 19:36:12 UTC
Created attachment 258337 [details]
this is everything journalctl displays related to this bug.
Comment 6 Felix Riemann 2013-10-28 20:22:07 UTC
Wow, looks like the driver is getting caught up in an endless recursion!
We should probably let the driver developers look into it before going on.
Comment 7 Christian Stadelmann 2013-10-28 20:56:00 UTC
How do we do that?
Comment 8 Felix Riemann 2013-10-28 22:24:13 UTC
I guess having the Fedora bug open should in the end trigger everything necessary. You can open a bug directly at Freedesktop (http://bugs.freedesktop.org) if it doesn't.
Comment 9 Jean-François Fortin Tam 2014-02-07 18:50:26 UTC
Hi Felix, I'm seeing pretty much the same issue on a Radeon HD 7770 with the open-source radeonsi driver on Fedora 20.

To reproduce, I simply need to try opening the full resolution version
(15,204 × 4,620 pixels) of http://commons.wikimedia.org/wiki/File:360-degree_Panorama_of_the_Southern_Sky_edit.jpg

...with eye of gnome. It will insta-crash X.org (since I don't have ABRT installed, it doesn't try grinding the disk for a backtrace).

Do note that GIMP has no trouble opening and viewing this image.
Comment 10 alex 2015-01-30 18:08:52 UTC
same problem here with a highresolution png file.
Viewing the wikipedia picture works fine in the browser (I use the driver r600). But opening the png file and most probably opening the image from wikipedia with eog will crash the gnome session.
I see two possible error causes:
1. Xorg crashes
2. Memory is overwritten

I attach a test picture which triggers the crash.
Comment 11 alex 2015-01-30 18:23:23 UTC
bad idea, I hope I stopped it. Forgot that it is about 100mb
Comment 12 Christian Stadelmann 2015-05-04 18:30:02 UTC
I cannot reproduce the original bug on gnome 3.16 / Fedora 22.
Comment 13 André Klapper 2015-07-25 14:54:19 UTC
Closing as OBSOLETE as GNOME 3.10 is not supported anymore and as it cannot be reproduced on 3.16.
Please reopen if this still can be triggered in GNOME 3.16 somehow.
Comment 14 Jean-François Fortin Tam 2015-07-25 15:50:42 UTC
I'm surprised, I thought I'd still manage to crash it with the wikimedia image but couldn't on 3.16/F22. A bit puzzled that this was not an issue with GIMP to start with, though.
Comment 15 Christian Stadelmann 2015-07-25 18:02:02 UTC
I cannot reproduce both. Seems good. Maybe someone else fixed this in X or Gtk or eog…