GNOME Bugzilla – Bug 519514
crash in Image Viewer: Opening an Image
Last modified: 2014-10-22 15:54:41 UTC
Version: 2.18.2 What were you doing when the application crashed? Opening an Image Distribution: Fedora release 7 (Moonshine) Gnome Release: 2.18.3 2007-11-13 (Red Hat, Inc) BugBuddy Version: 2.18.0 System: Linux 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 16:52:18 EST 2008 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: Fedora Memory status: size: 340082688 vsize: 340082688 resident: 6934528 share: 5238784 rss: 6934528 rss_rlim: 18446744073709551615 CPU usage: start_time: 1204293399 rtime: 1 utime: 1 stime: 0 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/eog' (no debugging symbols found) Using host libthread_db library "/lib64/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46912496355008 (LWP 8810)] [New Thread 1084229968 (LWP 8811)] (no debugging symbols found) 0x00000030152c82e6 in poll () from /lib64/libc.so.6
+ Trace 190846
Thread 2 (Thread 1084229968 (LWP 8811))
----------- .xsession-errors --------------------- at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447) at org.eclipse.equinox.launcher.Main.run(Main.java:1173) at org.eclipse.equinox.launcher.Main.main(Main.java:1148) 2:55:42 PM [error] ErrorListDialog$ErrorEntry: /home/ingo.wiese/Desktop/bumoLayout.jsp: 2:55:42 PM [error] ErrorListDialog$ErrorEntry: Cannot load with the encoding "UTF-8". 2:55:42 PM [error] ErrorListDialog$ErrorEntry: (java.nio.charset.MalformedInputException: Input length = 1) 2:55:42 PM [error] ErrorListDialog$ErrorEntry: Try selecting a different encoding. 2:55:42 PM [error] ErrorListDialog$ErrorEntry: It can be selected with the menu File->Reload with Encoding. 2:55:42 PM [error] ErrorListDialog$ErrorEntry: If you want it to be done automatically, add the candidates into 2:55:42 PM [error] ErrorListDialog$ErrorEntry: "List of fallback encodings" in Encodings pane of Global Options. Eog-ERROR **: file eog-image.c: line 777 (eog_image_real_load): assertion failed: (priv->image != NULL) aborting... warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff813fd000 --------------------------------------------------
Created attachment 106251 [details] A Mac PNG Its a png, but because it caused the crash i chose binary as content type
The png was taken as a screenshot on a mac.
Confirming. Apparently an error the PNG loader isn't catching. Updating GNOME version as we are not doing any work on 2.18 and 2.20 anymore.
Well, to make it short: That PNG file is heavily broken. It seems to have every 0-byte replaced by a space char(0x20) which makes most numerical values go crazy. For example the header is reporting an image size of 538968589x538968673px. It also seems to have HTML insertions all over it. Multiple times there is a HTML comment containing lots of spaces. Nonetheless we should catch that error (libpng appears to be reporting it as GIMP and ImageMagick are properly failing ) instead of crashing.
Assigning to gdk-pixbuf. gdk_pixbuf_loader_close erroneously returns TRUE meaning the image has been successfully loaded while it actually hasn't. It looks like only incremental loading is affected as the static file loading functions correctly return an error.
I made some debugging in this case and appears that libpng's incremental loader is not really fail-safe in this case. It starts to parse the file and reads the length for the header which is erroneously 538976269 Bytes due to the mixed up file contents. But instead of complaining (a PNG header chunk has a fixed size of 13 Bytes) it prepares a buffer and waits for the 538976269 Bytes to arrive which in this case will leave it waiting indefinitely. I'll see if I can prepare a test script exposing this.
(In reply to comment #6) > > I'll see if I can prepare a test script exposing this. > Turns out I don't have to. The libpng tarball contains the rpng2 tool which exposes this as well. I opened a bug against libpng: http://sourceforge.net/tracker/index.php?func=detail&aid=1911494&group_id=5624&atid=105624
libpng-1.2.26 (released on Wednesday) correctly triggers an error now: "Fatal error reading PNG image file: Invalid IHDR length". The patch in bug 524216 is also able to catch this inside gdk-pixbuf if an older libpng is used (error message is different though).
*** Bug 560749 has been marked as a duplicate of this bug. ***
Given this is sorted now with libpng >= 1.2.26, and bug 524216 handles the <1.2.26 case, can this be closed now?
Added the test to the git repository. commit 94ce8a0101a6bb839ee6cb474b1650dbcd1158fc Author: Bastien Nocera <hadess@hadess.net> Date: Wed Oct 22 17:53:25 2014 +0200 tests: Add test from bug 519514 https://bugzilla.gnome.org/show_bug.cgi?id=519514