GNOME Bugzilla – Bug 775514
Aborts on g_mutex_clear when force unmounting
Last modified: 2017-08-15 06:50:17 UTC
The afc daemon sometimes aborts on g_mutex_clear when force unmounting. I suppose that the mutex is locked and thus it aborts. However, I wonder why it can be locked, because it seems to me that we operate with the mutex only on the main thread... Backtrace: 1 __GI_raise 2 __GI_abort 3 g_mutex_clear 4 g_vfs_backend_afc_close_connection 5 force_umount_idle 6 g_idle_dispatch 7 g_main_context_dispatch 8 g_main_context_iterate 9 g_main_loop_run 10 daemon_main 11 main Source: https://retrace.fedoraproject.org/faf/problems/?component_names=gvfs&function_names=g_vfs_backend_afc_close_connection
Hadess, can you please try reproducing it and provide full backtrace?
Created attachment 341234 [details] [review] afc: Leak mutex when force unmounting The afc daemon sometimes aborts on g_mutex_clear when force unmounting. Leak the mutex in order to avoid the aborts. The daemon will hopefully finish successfully then...
Created attachment 341497 [details] [review] afc: Leak mutex when force unmounting
(In reply to Ondrej Holy from comment #0) > The afc daemon sometimes aborts on g_mutex_clear when force unmounting. I > suppose that the mutex is locked and thus it aborts. However, I wonder why > it can be locked, because it seems to me that we operate with the mutex only > on the main thread... There doesn't seem to be a reproducer for this, or a bugzilla report which would show the backtrace for every thread, if there is indeed another one. So the only possibility I see is something having already freed the mutex, or the structure it's in, possibly us. Let me try to reproduce.
I don't know how to reproduce the problem I'm afraid. Code analysis also didn't bring up anything obvious.
This will only happen when unplugging the device, not when umounting it cleanly, otherwise it wouldn't go through force_umount_idle(). Maybe a race between unmounting and unplugging? Seems unlikely.
Hmm, I though that the backend uses try_ methods initially, but it isn't, so force_unmount_idle is actually a different thread, because jobs are running on the thread pool... so the mutex can be actually locked, because some other job can be still running... so if we use the proposed patch and have some luck, it may finish the unmount properly...
Review of attachment 341497 [details] [review]: Based on comment 7, let's commit this.
Attachment 341497 [details] pushed as c110200 - afc: Leak mutex when force unmounting