GNOME Bugzilla – Bug 161997
gnome-vfs-daemon blocked in a mutex when hal restarts
Last modified: 2005-01-31 11:18:30 UTC
(gnome-vfs 2.9.2) When hal is restarted, gnome-vfs-daemon seems to be blocked in a mutex. Many applications are then blocked too (probably in gnome_vfs_get_volume_monitor) Here's a stack trace: (gdb) bt
+ Trace 53783
Lowering priority since this happens when the hal backend is enabled, and it's not enabled by default. Can you get a backtrace for the other threads ? (thread apply all bt) Fwiw, I tried to restart hal (or rather to do a /etc/init.d/dbus restart on a debian sid system) with gnome-vfs head compiled with ahl support about a week ago, and I didn't manage to hang gnome-vfs-daemon.
(gdb) thread apply all bt
+ Trace 53810
Thread 2 (Thread -1216922704 (LWP 1680))
I can't get anything better than this... Steps to reproduce: * /etc/init.d/dbus stop * kill gnome-vfs-daemon. A new gnome-vfs-daemon should be automatically spawned. * /etc/init.d/dbus start It's not always possible to reproduce, but sometimes it works.
*** Bug 163942 has been marked as a duplicate of this bug. ***
I just got this strace with GNOME 2.9.4 and gnomevfs built without hal while opening a gdmflexiserver with an another user on my box
(gdb) bt full
+ Trace 54611
Hrm, could this be an ORBit/bonobo bug? My understanding of this backtrace is that the client calls the registerVolumeMonitor method on the daemon. The daemon executes that method, and to do that, it needs to create a GnomeVFSVolumeMonitorDaemon object. In the _init method for this gobject, gconf_client_get_default is called. This causes another remote method (ConfigServer_ping ?) to be called, this time on the gconf daemon. But for some reason, registerVolumeMonitor gets called again (instead of the appropriate method on the gconf daemon), which causes the deadlock since the the_volume_monitor lock is held and hasn't been released yet. Dunno if I'm making sense, I'm tired and have drunk a bit too much, Alex will have to look at it anyway...
Ah, this is a corba reentrancy issue. While we're handling the first registerVolumeMonitor another one arrives, and when we call out using corba to gconfd we'll start handling the second one. One could possibly move registerVolumeMonitor() to AsyncDaemon, which is registered to launch a new thread per request. However, the whole locking scheme for volumes/drives is built upon changes only happening in the main thread, so that would require a massive redesign of that locking. Long term that might be nice anyway, to allow changing GnomeVFSVolumes after construction (not currently allowed due to locking scheme) but it sounds a bit much right now. A possible solution is to create the volume daemon in main() to avoid the gconf call.
Created attachment 36164 [details] [review] Possible fix Can someone please test this patch and see if it fixes the issue?
i commited this, because i do think its right, and i don't want to forget it. I'd still like someone to verify that it indeed fixes it though.
I've added it to the hoary package today. It fixed the issue for one guy who had it, but since that's a pretty random bug I'm not sure if that's just a luck or the patch. I've asked for feedback from all the users having the bug, I'll let you know if somebody still get the issue with it (quite a lot of people had it randomly before).
*** Bug 163579 has been marked as a duplicate of this bug. ***
no lock in 2 weeks with the patch, the bug seems to be fixed, I'm closing it.