Race between dbus interface unexport and client methods
Submitted by Ross Lagerwall
Assigned to gvf..@..e.bugs
Link to original bug (#731077)
Description
Created attachment 277684 test program
When the Unmount() method is called on a daemon, the daemon unexports the Mount interface and then goes into a shutdown procedure.
Any operation which is called on that daemon after this fails with "No such interface 'org.gtk.vfs.Mount' on object at path /org/gtk/vfs/mount/1".
Operations can be called on that same daemon due to the GMountInfo cache. Entries are only invalidated when the peer connection closes, which only happens when the daemon actually exits (some time after the Mount interface is unexported). Even without the GMountInfo cache, an operation executed concurrently with unmount() could fail in this way.
The only solution I can think of would be to retry operations that fail with G_DBUS_ERROR_UNKNOWN_METHOD after invalidating the GMountInfo cache entry. This would fix the problem, and AFAICT, would not have any side effects or races. I guess the question is whether it is a good solution or not. Experts' comments wanted :-)
Attached is a simple example to reproduce the problem. Sample output: """ $ ./unmount mount starting mount finishing mount finished finding enclosing mount finding enclosing mount finished unmount starting unmount finishing unmount finished query_info error: No such interface 'org.gtk.vfs.Mount' on object at path /org/gtk/vfs/mount/1 """
Attachment 277684, "test program":
unmount.c
Version: 1.21.x