Hi, I propose the attached patch for this. Upstream hasn't replied on this issue in their tracker in months, but for kfreebsd we need to do something, as a large backlog of packages are BD-Uninstallable in sid due to this. I think it is a recursion from the GUnixMountMonitor constructor, to a GLocalFileMonitor on /etc/fstab, and into GUnixMountMonitor again, now with a mutex already held, so it deadlocks. https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=235354 That mutex in glocalfile.c:g_local_file_find_enclosing_mount() doesn't seem necessary any more IMHO. Inside it, only 'mount' is modified, but that's just a stack variable local to this function. When klass->get_mount_for_mount_path is called, it's given one const parameter and the other is unused, so they're unchanged. 'klass' doesn't seem it could be modified either inside that function. It doesn't recurse infinitely, but seems to work correctly and pass the testsuite after this change. The FreeBSD project already applied my patch in their ports tree, and their users seem happy with it. If you don't want to apply the patch, because you have concerns it could create a regression on Linux, the mutex lock/unlock could be wrapped in #ifndef __FreeBSD_kernel__ instead. But I'm surprised the deadlock issue hasn't been seen on Linux, as the same generic "unix" implementation is used there as for kfreebsd. Thanks. Regards, -- Steven Chamberlain steven@pyro.eu.org
--- a/gio/gunionvolumemonitor.c
+++ b/gio/gunionvolumemonitor.c
@@ -591,11 +591,7 @@
mount = NULL;
if (klass->get_mount_for_mount_path)
- {
- g_rec_mutex_lock (&the_volume_monitor_mutex);
- mount = klass->get_mount_for_mount_path (mount_path, cancellable);
- g_rec_mutex_unlock (&the_volume_monitor_mutex);
- }
+ mount = klass->get_mount_for_mount_path (mount_path, cancellable);
/* TODO: How do we know this succeeded? Keep in mind that the native
* volume monitor may fail (e.g. not being able to connect to
Attachment:
signature.asc
Description: Digital signature