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.
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 i686/cmov/ libpthread. so.0 i686/cmov/ libpthread. so.0 i686/cmov/ libpthread. so.0 store_remove_ thumbnail_ job (store=0x81dcb10, 0xbf864c8c) at eog-list- store.c: 723 store_thumbnail _unset (store=0x81dcb10, 0xbf864c8c) at eog-list- store.c: 790 view_clear_ range (tb=<value optimized out>, view.c: 123 t_changed_ cb (tb=0x873a008, data=0x80e2710) at eog-thumb- view.c: 228 marshal_ VOID__VOID (closure=0x8477390, value=0x0, n_param_values=1, param_values= 0xbf864fe4, hint=0xbf864eec , marshal_ data=0x80832e0) buildd/ glib2.0- 2.16.6/ gobject/ gmarshal. c:77 invoke (closure=0x8477390, return_value=0x0, values= 1, param_values= 0xbf864fe4, invocation_ hint=0xbf864eec ) buildd/ glib2.0- 2.16.6/ gobject/ gclosure. c:490 emit_unlocked_ R (node=0x846d818, detail=0, 0x80e2710, emission_ return= 0x0, instance_ and_params= 0xbf864fe4) buildd/ glib2.0- 2.16.6/ gobject/ gsignal. c:2510
#0 0xb7fe1410 in __kernel_vsyscall ()
#1 0xb7e91589 in __lll_lock_wait () from /lib/tls/
#2 0xb7e8cba6 in _L_lock_95 () from /lib/tls/
#3 0xb7e8c58a in pthread_mutex_lock () from /lib/tls/
#4 0x08083a56 in eog_list_
iter=
#5 0x08083c93 in eog_list_
iter=
#6 0x08083262 in eog_thumb_
start_thumb=2, end_thumb=2) at eog-thumb-
#7 0x0808336b in tb_on_adjustmen
user_
#8 0xb75d4aef in IA__g_cclosure_
return_
invocation_
at /build/
#9 0xb75c7749 in IA__g_closure_
n_param_
at /build/
#10 0xb75dc319 in signal_
instance=
at /build/
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