Re: [Nautilus-list] gnome-vfs async race condition

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

Maciej Stachowiak <mjs eazel com> writes:

> Martin Baulig <martin home-of-linux org> writes:
> 
> > 
> > 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 really funny because I was just telling Pavel on IRC how
> invoking the main loop from random code would lead to race conditions
> that would cause crashes, and he was not entirely convinced this would
> apply to where it was getting used in gnome-vfs. Thanks for the timely
> example. :-)

Oh, that's really funny :-)

Unfortunately, I just discovered some more problems:

====
#0  corba_gnome_vfs_async_get_file_info (handle_return=0x8206100, uris=0xbffff044, options=13, 
    callback=0x407def08 <get_info_callback>, callback_data=0x820e500) at gnome-vfs-async-ops.c:421
#1  0x4074d627 in gnome_vfs_async_get_file_info (handle_return=0x8206100, uris=0xbffff044, options=13, 
    callback=0x407def08 <get_info_callback>, callback_data=0x820e500) at gnome-vfs-backend.c:643
#2  0x407df418 in start_getting_file_info (directory=0x820e500) at nautilus-directory-async.c:2326
#3  0x407dfa53 in start_or_stop_io (directory=0x820e500) at nautilus-directory-async.c:2508
#4  0x407dfb1e in nautilus_directory_async_state_changed (directory=0x820e500) at nautilus-directory-async.c:2550
#5  0x407df167 in get_info_callback (handle=0x821fce8, results=0x821b49c, callback_data=0x820e500)
    at nautilus-directory-async.c:2259
#6  0x40b0e524 in impl_Notify_get_file_info (servant=0x821fdc8, results=0xbffff51c, ev=0xbffff56c)
    at gnome-vfs-slave-notify.c:697
#7  0x40b03727 in _ORBIT_skel_GNOME_VFS_Slave_Notify_get_file_info (_ORBIT_servant=0x821fdc8, _ORBIT_recv_buffer=0x811a3d8, 
    ev=0xbffff56c, _impl_get_file_info=0x40b0e2e0 <impl_Notify_get_file_info>) at gnome-vfs-slave-skels.c:1280
#8  0x40154479 in ORBit_POA_handle_request (recv_buffer=0x811a3d8, poa=0x8119038) at orbit_poa.c:507
#9  0x4015761f in ORBit_handle_incoming_request (recv_buffer=0x811a3d8) at server.c:89
#10 0x40157964 in ORBit_handle_incoming_message (recv_buffer=0x811a3d8) at server.c:159
#11 0x40177cd6 in giop_main_handle_connection (connection=0x8220080) at connection.c:1211
#12 0x4010a0ec in orb_handle_connection (source=0x8220130, cond=G_IO_IN, cnx=0x8220080) at oaf-mainloop.c:69
#13 0x400d4552 in g_io_unix_dispatch (source_data=0x8219e28, current_time=0xbffff740, user_data=0x8220080) at giounix.c:135
#14 0x400d64e4 in g_main_dispatch (dispatch_time=0xbffff740) at gmain.c:656
#15 0x400d6d23 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#16 0x400d6f1c in g_main_run (loop=0x81277c8) at gmain.c:935
#17 0x404a74cd in gtk_main () at gtkmain.c:476
#18 0x401cafe5 in bonobo_main () at bonobo-main.c:271
#19 0x806e45d in main (argc=1, argv=0xbffffa54) at nautilus-main.c:243
====

In frame #5, we get a callback from the GnomeVFSSlave (which tells us that
it's done reading the file info) - and in this callback we call
nautilus_directory_async_state_changed() which results in
gnome_vfs_async_get_file_info() being called again on the same directory :-(

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