GNOME Bugzilla – Bug 567664
Properly implement unmounting
Last modified: 2011-06-05 11:40:49 UTC
Please describe the problem: After successfully mounting a webdav share, I am able to browse this. But once I eject this share, the desktop becomes unresponsive and nautilus goes into 100% CPU usage. The share I've connected to didn't require a login, nor was it over a secured connection. Steps to reproduce: 1. Connect to a webdav share, like dav://webdav.schlitt.info/ 2. Try to unmount/eject this share. 3. Fire up top(1) and watch nautilus eating the CPU. Actual results: The nautilus process hangs. Expected results: webdav share gets properly ejected and no hanging processes. Does this happen every time? Yes. Other information: This is on OpenBSD with the following relevant modules installed: glib2: 2.18.4 gtk+2: 2.14.7 gvfs: 1.0.3 nautilus: 2.24.2 Solaris seems to be having a similar issue: http://defect.opensolaris.org/bz/show_bug.cgi?id=4915
-> gvfs This should be a bug in the WebDAV GVfs backend.
I confirm this (mis)behaviour on OpenBSD-current with a GNOME 2.24 Desktop.
On Ubuntu 8.10 this bug is NOT present. glib2: 2.18.2-0ubuntu2 gvfs: 1.0.2-0ubuntu1 nautilus: 1:2.24.1-0ubuntu2
Can't reproduce with svn trunk. Can you try to get a backtrace from nautilus when this is happening? (attach to the process with gdb)
Here's a backtrace. I'm not sure it contains any interesting things though. After a while, nautilus cpu goes back down to 0% and the process STATE under top(1) is "stop". (gdb) bt full
+ Trace 213709
In fact, that is not so interesting. It just shows the main thread being idle. Maybe some other thread is spinning though. Can you try thread apply bt full
`thread apply bt full' gives no output at all.
Sorry, "thread apply all bt full"
Here you go. (gdb) thread apply all bt full
+ Trace 213756
Thread 1 (process 11334, thread 0x8b852c00)
I don't see anything that particularly looks like a 100% cpu loop in that. Maybe attaching with gdb breaks the loop?
Actually, yes it does. As soon as I attached the process to gdb, then cpu goes back to 0% (or so). These look suspicious: startup_id = 0x1 <Address 0x1 out of bounds> autostart_id = 0x1 <Address 0x1 out of bounds>
Well, gdb will freeze the process. Does it still run at 0% if you continue in gdb or de-attach? wrt to the 0x1 strings, things like this are generally just gdb sucking. However, if you suspect memory corruption, try running in valgrind.
If I detach the process from gdb, then it goes back to 100%. Running under valgrind is a no-go as it does not work under OpenBSD.
I am seeing the same problem on OpenSolaris with nautilus 2.26.2 also. The webdav mount can be browsed but when the eject book mark is clicked on, the gvfsd-dav process exists but then nautilus seems to spin as described. Though I noticed something else also, when I click on the mount under Places, I got an error, Could not display "davs://dev.storage.network.com/". Error: HTTP Error: Moved Temporarily Please select another viewer and try again. [OK] I wonder is that because there is a mismatch between what is mounted and what it tried to unmount that causes the spinning of nautilus.
(In reply to comment #14) > I am seeing the same problem on OpenSolaris with > nautilus 2.26.2 also. > The webdav mount can be browsed but when the eject book mark is clicked on, the > gvfsd-dav process exists but then nautilus seems to spin as described. > > Though I noticed something else also, when I click on the mount under Places, I > got an error, > > Could not display "davs://dev.storage.network.com/". > Error: HTTP Error: Moved Temporarily > Please select another viewer and try again. > > [OK] I've filed another bug http://bugzilla.gnome.org/show_bug.cgi?id=589221 for this issue, and a patch also was attached.
> I've filed another bug http://bugzilla.gnome.org/show_bug.cgi?id=589221 for > this issue, and a patch also was attached. Unfortunately, this does not resolve the original issue about nautilus going into 100% CPU usage.
(In reply to comment #16) > > I've filed another bug http://bugzilla.gnome.org/show_bug.cgi?id=589221 for > > this issue, and a patch also was attached. > > Unfortunately, this does not resolve the original issue about nautilus going > into 100% CPU usage. > You are right. I'm working on this issue.
*** Bug 582128 has been marked as a duplicate of this bug. ***
Using dbus-monitor to view the messages when clicking 'unmount' menu command. Following is the output of dbus-monitor --sesssion signal sender=org.freedesktop.DBus -> dest=(null destination) serial=12 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.249" string ":1.249" string "" signal sender=:1.7 -> dest=(null destination) serial=841 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=unmounted struct { string ":1.249" object path "/org/gtk/vfs/mount/1" string "WebDAV on storage.network.com" string "WebDAV on storage.network.com" string "" string ". GThemedIcon folder-remote folder" method call sender=:1.78 -> dest=org.gtk.vfs.Daemon serial=53 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=lookupMount error sender=:1.7 -> dest=:1.78 error_name=org.glib.GError.g_2Dio_2Derror_2Dquark.c16 reply_serial=53 string "The specified location is not mounted" method call sender=:1.78 -> dest=org.gtk.vfs.Daemon serial=54 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=lookupMount error sender=:1.7 -> dest=:1.78 error_name=org.glib.GError.g_2Dio_2Derror_2Dquark.c16 reply_serial=54 string "The specified location is not mounted" The unmount method on the daemon is not called successfully, it looks the 'unmount' dbus method is not even called. When the daemon received the 'NameOwnerChanged' message, it sends 'unmounted' signal immediately. This looks weird.
Nautilus calls a DBus method 'G_VFS_DBUS_MOUNT_OP_UNMOUNT' of gvfsd_webdav to unmount the webdav mount. But the expected reply never come. The server should not call 'exit(0)' to exit the process directly. It should give an reply and before exiting.
Created attachment 140094 [details] [review] Change the unmount service function of webdav backend This can solve the hang issue of Nautilus. But Nautilus window doesn't refresh after receiving 'unmounted' signal. This should be another bug.
(In reply to comment #21) > Created an attachment (id=140094) [edit] > Change the unmount service function of webdav backend > > This can solve the hang issue of Nautilus. But Nautilus window doesn't refresh > after receiving 'unmounted' signal. This should be another bug. > This fixes the issue for me on OpenBSD. On a side note, nautilus refreshes fine here. Thank you!
Created attachment 188334 [details] [review] Properly implement unmount
(In reply to comment #23) > Created an attachment (id=188334) [details] [review] > Properly implement unmount This works (OpenBSD) for me, thanks!
We (Alex) and myself are currently trying to implement this in a generic way for all backends (trying to fix bug 509606); but it is tricky to get all the stuff right and race-free. It will make the 3.2 release though, I hope. Thanks for looking at the Antoine!
I removed the custom unmount code (6abbff2a11c28660a090e8b9398fb19332380094) from the dav backend for now since just calling exit() is clearly wrong anyway. We will pick up the auto-busy umount code once bug 509606 is fixed.