GNOME Bugzilla – Bug 327323
gnome-thumb must not pass non-NULL keys with NULL values
Last modified: 2006-02-12 13:47:53 UTC
Steps to reproduce: 1. Add a new picture (jpg, png, tiff tested) or video (ogg theora tested) to desktop or opened folder 2. Nautilus start thumbnailing 3. Nautilus crash Stack trace: Backtrace was generated from '/opt/gnome2/libexec/<unknown>' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1227966784 (LWP 1695)] [New Thread -1268417616 (LWP 2264)] [New Thread -1230214224 (LWP 1703)] 0xffffe410 in ?? ()
+ Trace 65279
Thread 3 (Thread -1230214224 (LWP 1703))
Other information: Yes, I wish. First the libgnomui crash alert don't show any text: just the error icon and close/inform button (no restart button). Second after the crash and the nautilus restart the thumbnail for the failed file appears. Third: no crash opening themes:// location. Fourth: please look the "log_level=G_LOG_LEVEL_CRITICAL" :-)
I'm seeing this too, on Ubuntu Dapper.
*** Bug 327838 has been marked as a duplicate of this bug. ***
seems to happen when png thumbnails are saved. real_save_png() calls g_convert with a NULL string
Well, it calls g_convert with the strings that were passed down by gnome_thumbnail_factory_save_thumbnail. It would be instructive to see the keys and values arrays that are being passed down.
just stumbled into this myself this lacks a few values but is detailed. Matthias?
+ Trace 65415
If you can repeat, what we really need to see is keys[i], values[i] for i = 0, 1, 2... At some point you must hit a non-NULL key with a NULL value
(gdb) print keys[0] $12 = (gchar *) 0x85c0cb0 "tEXt::Thumb::Image::Width" (gdb) print values[0] $13 = (gchar *) 0x0 (gdb) print keys[1] $15 = (gchar *) 0x8438830 "tEXt::Thumb::Image::Height" (gdb) print values[1] $16 = (gchar *) 0x0 (gdb) print keys[2] $17 = (gchar *) 0x84271e0 "tEXt::Thumb::URI" (gdb) print values[2] $18 = (gchar *) 0x850f788 "file:///home/nazgul/arborian1c.jpg" (gdb) print keys[3] $19 = (gchar *) 0x8539e18 "tEXt::Thumb::MTime" (gdb) print values[3] $20 = (gchar *) 0x85a85b8 "1137286555" (gdb) print keys[4] $21 = (gchar *) 0x8464560 "tEXt::Software" (gdb) print values[4] $22 = (gchar *) 0x846da48 "GNOME::ThumbnailFactory" (gdb) print keys[5] $23 = (gchar *) 0x0 (gdb) print values[5] $24 = (gchar *) 0x0
Yes, so thats a gnome-thumb bug then. It must not pass non-NULL keys with NULL values
*** Bug 327881 has been marked as a duplicate of this bug. ***
Regression from bug 143470.
The problem arises because gnome-thumbnail assumes that the pixbuf it's saving as thumbnail has previously generated by gnome-thumbnail. But nautilus' libnautilus-private/nautilus-thumbnail.c::nautilus_update_thumbnail_file_copied copies the thumbnail for a copied file, after loading it as normal pixbuf; so it doesn't have the gobject data set. This suggests that apart from fixing this assumption, we need a) a gnome_thumbnail_factory_save_thumbnail_with_size call which lets you provide the original image's size, and b) a gnome_thumbnail_factory_copy_thumbnail (old_uri, new_uri) to just associate the old_uri's thumbnail info also with new_uri. Since we're already past feature freeze, we need to either move quickly and get approval for a break, or punt the API part to 2.15.
also happens when adding new wallpapers to the backgrounds capplet making this a blocker because of its severe impact
*** Bug 327990 has been marked as a duplicate of this bug. ***
*** Bug 328110 has been marked as a duplicate of this bug. ***
Created attachment 57837 [details] Backtrace after crash I filed dupe 327990. I just had this crash happen with thumbnails turned off. I moved a file from my desktop to a directory in my home, noticed the file was still on the desktop, opened the destination directory and had the crash happen.
Bug 328129 has a patch attached. marking it a dependency.
The patch from bug 328129 doesn't fix this crash.
neither for me
*** Bug 328251 has been marked as a duplicate of this bug. ***
Should we back out the patch from Jimbob above then for the time being? Does everything work without that one?
what patch from whom? :) The patch from bug 328129 has never been commited.
For the record, I'm seeing a similar crash with gthumb as well.
*** Bug 328235 has been marked as a duplicate of this bug. ***
*** Bug 328631 has been marked as a duplicate of this bug. ***
Created attachment 58126 [details] [review] quick fix. This is probably not the desired solution, but at least it prevents the crash by getting the width/height info directly from the pixbuf only when the keys are not set. This way we wouldn't need to break API freeze.
patch works for me. this is no real fix but a workaround. I see two options: a) fix the real problem before the final release b) apply the workaround in case the real fix does not make it solution (a) is most preferrable since the bug causes other crashers as well.
The thumbnail spec (http://jens.triq.net/thumbnail-spec/creation.html) says the width/height properties are optional, so we should just leave them out if we don't know them. However, in the case of copy of a thumbnail we can know them, because they are read by gdk-pixbuf from the old thumbnail and availible with gdk_pixbuf_get_option (thumbnail, "tEXt::Thumb::Image::Width"). Ideally we should maybe have a with_size API addition, but i'm commiting a patch that fixes this for all normal cases.
Created attachment 58141 [details] [review] better fix
patch works for me and looks better than the previous one
*** Bug 328129 has been marked as a duplicate of this bug. ***
Alex, I can see you have commited the patch. the crash is gone.