eog will not open if set to display collection.

[Zachary Larsen]

Binary package hint: eog

Eye of Gnome 2.24 (Ubuntu Intrepid) will not load when I double-click on an image, if I left it set to display image collection. To reproduce, open an image in eog, select View-Image Collection, close eog, and logout. Log back in, and double-click an image, and note that EOG will not open. A process for eog will be visible in the processes tab of System Monitor.

This is running Ubuntu Intrepid i386 on a Dell Latitude D820 with Version 177 of the proprietary nVidia driver.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

[Todd Lewis (utoddl)]

This still happens with Hardy with updates through 2008.12.22.
GNOME eog 2.22.3
.xsession-errors contains the following message:

** (eog:12052): WARNING **: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

strace shows this:

$ strace -p 11929
Process 11929 attached - interrupt to quit
futex(0x8404998, 0x80 /* FUTEX_??? */, 2

Further info: The only recovery procedure I've found is to:
 1. kill all hung eog processes running in the background (ps; kill ... or reboot)
 2. open eog from the command line with no parameters
 3. when eog opens (which is will in this case with no parms), go to the View menu and un-check "Image collection"
 4. exit, so the persistent setting is saved
Restarting eog from the "Image Viewer" context menu works again.

[Pedro Villavicencio (pedro)]

are you still having this issue? could you install the libgtk2, libglib and eog dbgsym packages and get a new trace if you're still having the issue? thanks in advance!.

[Todd Lewis (utoddl)]

Pedro, yes, I'm still seeing this behavior, but I've been able to isolate it to a particular relevant piece of information: It only seems to happen if the folder containing the images is on a vfat file system.

I installed the libs you indicated, and ran eog under gdb until it hung, did a ^C and "bt", and here's the first part of what I got. There's probably a better way to get useful information, but I don't do this low level stuff very much. (Is it obvious?)

(gdb) bt
#0 0xb7fe1410 in __kernel_vsyscall ()
#1 0xb7e91589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7e8cba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb7e8c58a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4 0x08083a56 in eog_list_store_remove_thumbnail_job (store=0x81dcb10,
    iter=0xbf864c8c) at eog-list-store.c:723
#5 0x08083c93 in eog_list_store_thumbnail_unset (store=0x81dcb10,
    iter=0xbf864c8c) at eog-list-store.c:790
#6 0x08083262 in eog_thumb_view_clear_range (tb=<value optimized out>,
    start_thumb=2, end_thumb=2) at eog-thumb-view.c:123
#7 0x0808336b in tb_on_adjustment_changed_cb (tb=0x873a008,
    user_data=0x80e2710) at eog-thumb-view.c:228
#8 0xb75d4aef in IA__g_cclosure_marshal_VOID__VOID (closure=0x8477390,
    return_value=0x0, n_param_values=1, param_values=0xbf864fe4,
    invocation_hint=0xbf864eec, marshal_data=0x80832e0)
    at /build/buildd/glib2.0-2.16.6/gobject/gmarshal.c:77
#9 0xb75c7749 in IA__g_closure_invoke (closure=0x8477390, return_value=0x0,
    n_param_values=1, param_values=0xbf864fe4, invocation_hint=0xbf864eec)
    at /build/buildd/glib2.0-2.16.6/gobject/gclosure.c:490
#10 0xb75dc319 in signal_emit_unlocked_R (node=0x846d818, detail=0,
    instance=0x80e2710, emission_return=0x0, instance_and_params=0xbf864fe4)
    at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2510

As described above, running "eog filename.jpg" hangs before opening any window as described above when on vfat file system with "view collection" enabled at a previous eog close. At that point strace shows:
> ~$ strace -p 7696
> Process 7696 attached - interrupt to quit
> futex(0x85f3000, 0x80 /* FUTEX_??? */, 2

However, running
$ strace -f eog img_0528.jpg
does not hang. (You get a lot of messages indicating eog is probably doing a bunch of polling it shouldn't be doing, but that's a different problem altogether.) It opens the window (eventually), displays the image and the collection (eventually), and responds to actions. Well, eventually; strace really slows things down, which I suspect is part of why it seems to work under strace and not when running flat out.

Hope something in here is helpful. -- Todd

[Todd Lewis (utoddl)]

Here's a better backtrace, following the instructions this time. Perhaps this is more helpful. (It's certainly bigger.)

[Todd Lewis (utoddl)]

I was mistaken. It's also happening with folders on an ext3 file system.

[Sebastien Bacher (seb128)]

could you open the bug on bugzilla.gnome.org since you seem to be the only one to get the issue?

[Todd Lewis (utoddl)]

I have opened http://bugzilla.gnome.org/show_bug.cgi?id=572013 as Sebastien suggested.

[Pedro Villavicencio (pedro)]

Thanks you for sent it to GNOME.

[Todd Lewis (utoddl)]

For those still following this bug, if you disable "Assistive Technologies" the problem goes away... or at least hides better.

[Zachary Larsen (chiefmanyrabbitguteat)]

As of Jaunty, this has not been an issue.