GNOME Bugzilla – Bug 449409
Eog hangs when trying to open CR2 image (Canon RAW v2)
Last modified: 2007-09-04 20:56:27 UTC
I have put sample file up to http://plaes.org/files/2007-Q2/img_5055.cr2 Unfortunately CR2 is one of these unsupported and undocumented file formats :(
Yes, this only happens if you try to open it from the command line. It correctly returns an error if you try it with the file-open dialog. I suspect this could be related bug 439908.
It looks like some locking issues. It only happens to me with trunk (2.18 returns an appropriate error message). The traces in the place of the lock: Program received signal SIGTSTP, Stopped (user). [Switching to Thread -1229322560 (LWP 10141)] 0xb7fc77f2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) thread apply all where
+ Trace 142688
Thread 2 (Thread -1232364656 (LWP 10148))
Interesting. Just comment out the gtk_window_set_default_icon_name ("eog"); line in main.c and the window is displayed and shows the error (although it seems to eat the whole file first). It even opens SVGs (bug 439908). I wonder where the actual error is to find (eog, gdk-pixbuf, librsvg). By the way, your trace has some similarities in the upmost frames with the one I got in bug 447063, which seems to be worked-around by that too (although it doesn't display correctly).
Yeah, this is a pretty bad problem, with no easy solution right now. The problem is that some of the image libraries used by gdk-pixbuf are not threadsafe. Therefore, we have introduced locking some time ago. What is happening now is the following: - eog creates a pixbuf loader for incrementally loading the unsuppored image; for some reason gdk-pixbuf decides to try the non-threadsafe tiff loader for it. Thus it locks the gdk-pixbuf lock. - while feeding data to the loader, eog emits some signals that cause ui to be constructed - most images loaded during the ui construction are pngs and the png module is threadsafe. - but some are svg, and the svg loader is not threadsafe, thus gdk-pixbuf tries to lock again, and blocks on the lock taken earlier.
I don't have a very good solution to offer right now. You are having bad luck here, the tiff loader is the only builtin loader that is not threadsafe. Here is a thread with some hints on the libtiff <> threads situation: http://www.anonymouse.ru/cgi-bin/nph-proxy_ru.cgi/000111A/http/www.asmail.be/msg0054568393.html Looking at that it may be possible to rework the tiff loader to be threadsafe, but it is going to require some work. In the meantime, all we could do is offer a gdk_pixbuf_loader_is_locked() api that you could use to avoid the deadlock...
*** Bug 439908 has been marked as a duplicate of this bug. ***
Hmm, would it suffice to assign the tiff context (or whatever object is required to do error reporting) to a GStaticPrivate object and retrieve it in the error_handler? Somewhat like this: static GStaticPrivate thread_context; ... error_handler () { Context ctx = g_static_private_get (thread_context) ... report_error (ctx, error); ... } init_func () { Context ctx = new_context (); ... g_static_private_set (thread_context, ctx); ... } Otherwise I don't have any other idea on how to solve that; even the current development versions of libtiff seem to have this ugly way of error reporting.
Just noticed that this would still not fix it if you'd try to use two such loaders from the same thread. :-(
Created attachment 94098 [details] [review] possible workaround (work-in-progress) This a work-in-progress patch to workaround those threadunsafe loaders. It simply tries to delay the emission of the EogImage:size-prepared signal until the loader has finished. Seems to work good so far. The only downside is that the UI shows up after having completed loading (as in EOG < 2.19) . It currently uses the GdkPixbufFormat structure directly because there is no accessor function yet for the thread-safety attribute, but I'm going to prepare a patch for GTK+ to change that.
GTK+ bug to add gdk_pixbuf_format_is_threadsafe(): bug 469209
GNOME 2.20.0 code freeze is next week and eog is still hanging when trying to open a svg
Ok, I refactored Felix' patch (Thanks Felix!) and it really seems to work around this non-threadsafe loader problem. Fixed in trunk. 2007-09-04 Lucas Rocha <lucasr@gnome.org> * src/eog-image-private.h: added threadsafe_format private attribute. * src/eog-image.c (+eog_image_pre_size_prepared, eog_image_size_prepared, eog_image_real_load): detect non-threadsafe loaders and disable any possible asyncronous task that could bring deadlocks to image loading process. Fixes bug #449409 (Felix Riemann).