GNOME Bugzilla – Bug 403255
gdk_pixbuf_loader_close returns TRUE but sets *error
Last modified: 2010-07-10 04:06:32 UTC
Steps to reproduce: 1. Grab the attached file 2. And browse for the folder where it was saved Stack trace: Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.17.90 2007-01-25 (GARNOME) BugBuddy Version: 2.17.3 System: Linux 2.6.17-10-386 #2 Tue Dec 5 22:26:18 UTC 2006 i686 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: No Accessibility: Disabled Memory status: size: 82972672 vsize: 0 resident: 82972672 share: 0 rss: 31895552 rss_rlim: 0 CPU usage: start_time: 1170338636 rtime: 0 utime: 182 stime: 0 cutime:163 cstime: 0 timeout: 19 it_real_value: 0 frequency: 0 Backtrace was generated from '/opt/gnome/bin/nautilus' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1227979088 (LWP 5699)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 107133
Thread 1 (Thread -1227979088 (LWP 5699))
----------- .xsession-errors (6 sec old) --------------------- ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed aborting... -------------------------------------------------- Other information: The file type returned by 'file' tool is : $ file /tmp/tmp5f60d674.tmp /tmp/tmp5f60d674.tmp: JPEG image data, JFIF standard 1.01 ..although, this file header might be fake. Gimp recognize it as an image but also can't open it.
Created attachment 81672 [details] The tmp file with fake header
Created attachment 81673 [details] [review] Check the 'error' var before trying to get the pixbuf This patch seems to be a solution to this error. Now nautilus outputs: ** Message: Failed load thumbnail image /tmp/tmp5f60d674.tmp: Error interpreting JPEG image file (Improper call to JPEG library in state 201) without crashing anymore.
I did this instead: - if (!gdk_pixbuf_loader_close (loader, &error)) { + if (!gdk_pixbuf_loader_close (loader, &error) || + /* Seems we have to check this even if it returned TRUE (#403255) */ + error != NULL) { But its strange, this seems like a bug in gdk_pixbuf_loader_close.
The only possibility I see for gdk_pixbuf_loader_close to return TRUE and set error is if the loader module is broken and does just that in its stop_load function. We should probably protect against that.
2007-02-06 Matthias Clasen <mclasen@redhat.com> * gdk-pixbuf-loader.c (gdk_pixbuf_loader_close): Protect against stop_load begin broken. (#403255, Lucas Mazzardo Veloso)
*** Bug 385641 has been marked as a duplicate of this bug. ***