Bug 17778

Summary: eog aborts on attempt to display a very large image
Product: Mageia Reporter: Len Lawrence <tarazed25>
Component: RPM PackagesAssignee: Cesar Vargas <cvargas>
Status: RESOLVED OLD QA Contact:
Severity: normal    
Priority: Normal CC: cvargas, marja11, pkg-bugs
Version: 5   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: eog-3.14.3-1.1.mga5.src.rpm CVE:
Status comment:
Attachments: Large image 27000x27000
Strace log from eog test on large image
Cauldron strace for eog
Cauldron strace for eom

Description Len Lawrence 2016-02-15 16:38:26 CET
Description of problem:
During QA testing of an update, bug #17746, which addressed an integer overflow problem, eog aborted when trying to display the test image, a 27000x27000 PNG.  This may or may not be a manifestation of the same bug, but the error message differed from the pixel buffer error seen before: 
(eog:2269): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2.

Version-Release number of selected component (if applicable):
3.14.3-1.1
Install lib64eog-gir3.0-3.14.3-1.1.mga5 as well

How reproducible:
Repeatable, on different machines, tested under Mate and on i586 virtual machine as well.

Steps to Reproduce:
1. eog big.png
2. Wait for eog display window to disappear
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Len Lawrence 2016-02-15 16:43:22 CET
Created attachment 7461 [details]
Large image 27000x27000

Test image from https://bugs.mageia.org/show_bug.cgi?id=#7746
Comment 2 Len Lawrence 2016-02-15 16:48:45 CET
Created attachment 7463 [details]
Strace log from eog test on large image

Before the eog image appears there is a successful search for libeog.so.
For the record:
[lcl@vega ~]$ ls /usr/lib64/eog
girepository-1.0  libeog.so  plugins

Have snipped the memory remap section which accompanies the attempt at rendering the image in the eog window.

After the image window disappears the memory is unmapped and several messages
like the following appear before the final abort.

open("/home/lcl/.nv/nvidia-application-profile-globals-rc", O_RDONLY) = -1 ENOENT (No such file or directory)

[lcl@vega ~]$ ls .nv
GLCache
[lcl@vega ~]$ ls .nv/GLCache/*
.nv/GLCache/1de85065f23b7e5beeca342c4e04c1cc:
e973ec6d17999b01
..........

10 subdirectories in the cache.
David Walser 2016-02-15 16:55:50 CET

Assignee: bugsquad => olav

David Walser 2016-02-15 16:56:33 CET

CC: (none) => cvargas

Olav Vitters 2016-02-15 19:50:45 CET

Assignee: olav => bugsquad

Comment 3 Marja Van Waes 2016-02-15 21:11:38 CET
Assigning to vaci0 then (since the original assignee assigned back to bugsquad, and because Cesar is registered as maintainer for eog.

However, I don't remember when I've last seen him, so also CC'ing pkg-bugs@ml.m.o

CC: (none) => marja11, pkg-bugs
Assignee: bugsquad => cvargas

Comment 4 David Walser 2016-02-16 20:03:00 CET
Why did the GNOME maintainer take himself off of this bug?  Does nobody care about bugs in GNOME?  I did ask Len to try to reproduce this on Cauldron, and if it can be reproduced there, upstream needs to be made aware.  Who's going to take care of that?
Comment 5 Len Lawrence 2016-02-17 12:40:44 CET
Both eom and eog exhibit the same fault on big.png in Cauldron, at least the symptoms look the same.  The strace outputs may be different.  I am attaching the strace files here but should a new bug be filed against Cauldron?

eog-3.19.90-1.mga6.x86_64
eom-1.13.0-3.mga6.x86_64
Comment 6 Len Lawrence 2016-02-17 12:42:41 CET
Created attachment 7467 [details]
Cauldron strace for eog
Comment 7 Len Lawrence 2016-02-17 12:43:32 CET
Created attachment 7468 [details]
Cauldron strace for eom
Comment 8 Len Lawrence 2016-02-17 15:21:28 CET
Note that in Cauldron booted to the GNOME desktopeog  eog fails to respond when big.png is opened with the file manager inside eog and crashes after five or six seconds.  Called from the command line:
$ eog big.png
no gui appears and the system posts a failure to respond message.
Comment 9 Len Lawrence 2016-05-09 16:51:57 CEST
x86_64

Checked eog in GNOME installed from the 6sta1 classic iso and there is still a problem.  Whether big.png is specified on the commandline or via the internal file manager the system hangs and no image appears, only the display window.  The process soaks up 99% of the CPU power so it is a long time before Ctrl-C is effective.
Comment 10 Cesar Vargas 2016-10-18 22:49:53 CEST
Multiple reports were made, no definite solution yet
https://bugzilla.gnome.org/show_bug.cgi?id=709908
Comment 11 Len Lawrence 2017-05-07 22:55:42 CEST
Just checked this on latest Cauldron iso installation (6RC).
The test image can now be displayed by eog - dimensions 35000x400 reported.
We should consider this fixed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 12 Len Lawrence 2017-05-07 23:05:40 CEST
Perhaps not.  The test image was downloaded from the link under the reference in comment 10.  That worked fine but the image used in the original test could not be displayed.
$ eog big.png
(eog:18187): EOG-WARNING **: Error loading Eog typelib: Typelib file for namespace 'Eog', version '3.0' not found
(eog:18187): libpeas-WARNING **: Type not found in introspection: 'EogApplicationActivatable'
(eog:18187): libpeas-WARNING **: Method 'EogApplicationActivatable.activate' was not found
(eog:18187): libpeas-WARNING **: Type not found in introspection: 'EogWindowActivatable'
(eog:18187): libpeas-WARNING **: Method 'EogWindowActivatable.activate' was not found
Gdk-Message: eog: Fatal IO error 2 (No such file or directory) on X server :0.

Reverting status.

Resolution: FIXED => (none)
Status: RESOLVED => REOPENED

Comment 13 Marja Van Waes 2018-09-18 15:32:20 CEST

Hi Len,

Thank you for having taken the needed time to report this issue!

We regret if this issue didn't get fixed in Mageia 5.

Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/
It continued to get limited extended support since then, but that support has now ended, too.

I assume this bug doesn't exist in Mageia 6 or later, because eog has much newer versions there.

Closing as OLD.

Please reopen this report and change its "Version:" at the top left to "6", if the same bug still exists in Mageia 6.

Status: REOPENED => RESOLVED
Resolution: (none) => OLD