GNOME Bugzilla – Bug 678758
GTlsInteraction unlocks an unlocked mutex
Last modified: 2012-06-28 12:48:00 UTC
There is at least one case in GLib where a mutex is unlocked by a thread that does not own the mutex. On Linux, the default (and adaptive) mutex does not do error checking to see if the current thread owns the mutex. On FreeBSD (and other BSDs) the default mutex will check to make sure the current thread is the owner before it will allow the mutex to be unlocked. My personal thinking on this is that even on Linux a thread should not be unlocking a mutex it does not own. Here is a stack trace showing the problem. # gdb /usr/ports/devel/glib20/work/glib-2.32.3/gio/tests/.libs/tls-interaction (gdb) r Starting program: /usr/ports/devel/glib20/work/glib-2.32.3/gio/tests/.libs/tls-interaction [New LWP 108325] [New Thread 802807400 (LWP 108325/tls-interaction)] /tls-interaction/ask-password/invoke-with-loop/unhandled-implementation: [New Thread 80280a000 (LWP 108374/tls-interaction)] [Thread 80280a000 (LWP 108374/tls-interaction) exited] OK /tls-interaction/ask-password/invoke-with-loop/async-implementation-success: [New Thread 80280a400 (LWP 107806/tls-interaction)] [Thread 80280a400 (LWP 107806/tls-interaction) exited] OK /tls-interaction/ask-password/invoke-with-loop/async-implementation-failure: [New Thread 80280a800 (LWP 108375/tls-interaction)] [Thread 80280a800 (LWP 108375/tls-interaction) exited] OK /tls-interaction/ask-password/invoke-with-loop/sync-implementation-success: [New Thread 80280ac00 (LWP 105756/tls-interaction)] [Thread 80280ac00 (LWP 105756/tls-interaction) exited] OK /tls-interaction/ask-password/invoke-with-loop/sync-implementation-failure: [New Thread 80280b000 (LWP 108376/tls-interaction)] [Thread 80280b000 (LWP 108376/tls-interaction) exited] OK /tls-interaction/ask-password/invoke-without-loop/unhandled-implementation: OK /tls-interaction/ask-password/invoke-without-loop/async-implementation-success: GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_unlock': Operation not permitted. Aborting. Program received signal SIGABRT, Aborted.
+ Trace 230422
Thread 802807400 (LWP 108325/tls-interaction)
As you can see g_tls_interaction_invoke_ask_password() tries to unlock a mutex it does not own (i.e., pthread_mutex_unlock() returns EPERM). In looking at some other test suites, I believe there are other such examples in GLib.
see also bug 674822
Running a full "make check" with PTHREAD_MUTEX_ERRORCHECK, tls-interaction is the only test that fails. The g_main_context_acquire()-succeeds branch of g_tls_interaction_invoke_ask_password() does g_mutex_unlock (&closure->mutex); g_main_context_iteration (interaction->priv->context, TRUE); g_mutex_lock (&closure->mutex); but closure->mutex is unlocked at that point. I'm not sure what it intended to be doing there...
Created attachment 217519 [details] [review] GTlsInteraction: Fix incorrect locking of mutex * Fix incorrect locking of mutex in g_tls_interaction_invoke_ask_password()
Comment on attachment 217519 [details] [review] GTlsInteraction: Fix incorrect locking of mutex ok. could maybe use atomics/volatile instead in the future, but this at least fixes the bug