[Nautilus-list] gnome-vfs async race condition

[Martin Baulig <martin home-of-linux org>]

Hi guys,

just discovered a little problem in the libgnomevfs-corba:

=====
#0  start_getting_file_info (directory=0x820da28) at nautilus-directory-async.c:2310
#1  0x407df9e3 in start_or_stop_io (directory=0x820da28) at nautilus-directory-async.c:2498
#2  0x407dfaae in nautilus_directory_async_state_changed (directory=0x820da28) at nautilus-directory-async.c:2540
#3  0x407dc37c in dequeue_pending_idle_callback (callback_data=0x820da28) at nautilus-directory-async.c:945
#4  0x400d7a4a in g_idle_dispatch (source_data=0x407dc058, dispatch_time=0xbffff420, user_data=0x820da28) at gmain.c:1365
#5  0x400d64e4 in g_main_dispatch (dispatch_time=0xbffff420) at gmain.c:656
#6  0x400d6d23 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#7  0x400d6f1c in g_main_run (loop=0x820eeb0) at gmain.c:935
#8  0x40b0d10d in get_ior (fd=40) at gnome-vfs-slave-launch.c:87
#9  0x40b0d377 in gnome_vfs_slave_launch (notify_object=0x8120918, request_objref_return=0x820ea58)
    at gnome-vfs-slave-launch.c:172
#10 0x40b0e9a7 in gnome_vfs_slave_process_new () at gnome-vfs-slave-process.c:78
#11 0x40b0c4b5 in corba_gnome_vfs_async_get_file_info (handle_return=0x8205f30, uris=0xbffff5c4, options=13, 
    callback=0x407def08 <get_info_callback>, callback_data=0x820da28) at gnome-vfs-async-ops.c:421
#12 0x4074d627 in gnome_vfs_async_get_file_info (handle_return=0x8205f30, uris=0xbffff5c4, options=13, 
    callback=0x407def08 <get_info_callback>, callback_data=0x820da28) at gnome-vfs-backend.c:643
#13 0x407df3a2 in start_getting_file_info (directory=0x820da28) at nautilus-directory-async.c:2316
#14 0x407df9e3 in start_or_stop_io (directory=0x820da28) at nautilus-directory-async.c:2498
#15 0x407dfaae in nautilus_directory_async_state_changed (directory=0x820da28) at nautilus-directory-async.c:2540
#16 0x407dc37c in dequeue_pending_idle_callback (callback_data=0x820da28) at nautilus-directory-async.c:945
#17 0x400d7a4a in g_idle_dispatch (source_data=0x407dc058, dispatch_time=0xbffff750, user_data=0x820da28) at gmain.c:1365
#18 0x400d64e4 in g_main_dispatch (dispatch_time=0xbffff750) at gmain.c:656
#19 0x400d6d23 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#20 0x400d6f1c in g_main_run (loop=0x81276f0) at gmain.c:935
#21 0x404a74cd in gtk_main () at gtkmain.c:476
#22 0x401cafe5 in bonobo_main () at bonobo-main.c:271
#23 0x806e3cd in main (argc=1, argv=0xbffffa64) at nautilus-main.c:243
====

The problem is the following:

* in frame #13, Nautilus calls gnome_vfs_async_get_file_info() which launches
  a new GnomeVFSSlave and this results in an invocation of the GLib main loop.
* at the time the GLib main loop is entered, *handle_return is not yet written
  so (in start_getting_file-info) directory->details->get_info_in_progress is
  still NULL.
* inside the main loop we may get an event which results in
  start_getting_file_info() on the same directory being called - and here
  comes the problem: since gnome-vfs hasn't assigned us a handler yet, we
  call gnome_vfs_async_get_file_info() on the same directory again.

This is not such a big problem in the pthread backend and for the corba one
I think you'll also only run into it if you're on a slow machine where
launching a new GnomeVFSSlave involves some swapping and thus the main loop
has a chance to run for a while.

But you may also run into this problem with the pthreads, for instance when
you run it in gdb (where, on my machine, it swaps and thus get slow enough).

IMO the best way to fix this problem is to always write *handler_return
before starting any async operations everywhere in gnome-vfs-async-ops.c.

What do you think ?

(Btw. is there a gnome-vfs mailing list or where is the correct place to
 discuss such things ?)

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)