After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678758 - GTlsInteraction unlocks an unlocked mutex
GTlsInteraction unlocks an unlocked mutex
Product: glib
Classification: Platform
Component: gio
Other FreeBSD
: Normal critical
: ---
Assigned To: gtkdev
Depends on:
Reported: 2012-06-25 07:47 UTC by Joe Marcus Clarke
Modified: 2012-06-28 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

GTlsInteraction: Fix incorrect locking of mutex (1.62 KB, patch)
2012-06-28 12:43 UTC, Stef Walter
committed Details | Review

Description Joe Marcus Clarke 2012-06-25 07:47:37 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:
[New LWP 108325]
[New Thread 802807400 (LWP 108325/tls-interaction)]
[New Thread 80280a000 (LWP 108374/tls-interaction)]
[Thread 80280a000 (LWP 108374/tls-interaction) exited]
[New Thread 80280a400 (LWP 107806/tls-interaction)]
[Thread 80280a400 (LWP 107806/tls-interaction) exited]
[New Thread 80280a800 (LWP 108375/tls-interaction)]
[Thread 80280a800 (LWP 108375/tls-interaction) exited]
[New Thread 80280ac00 (LWP 105756/tls-interaction)]
[Thread 80280ac00 (LWP 105756/tls-interaction) exited]
[New Thread 80280b000 (LWP 108376/tls-interaction)]
[Thread 80280b000 (LWP 108376/tls-interaction) exited]
/tls-interaction/ask-password/invoke-without-loop/unhandled-implementation: OK
GLib (gthread-posix.c): Unexpected error from C library during
'pthread_mutex_unlock': Operation not permitted.  Aborting.

Program received signal SIGABRT, Aborted.

Thread 802807400 (LWP 108325/tls-interaction)

  • #0 thr_kill
    from /lib/
  • #1 abort
    from /lib/
  • #2 g_thread_abort
    at gthread-posix.c line 76
  • #3 g_tls_interaction_invoke_ask_password
    at gtlsinteraction.c line 353
  • #4 test_invoke_ask_password
    at tls-interaction.c line 288
  • #5 g_test_run_suite_internal
    at gtestutils.c line 1663
  • #6 g_test_run_suite_internal
    at gtestutils.c line 1727
  • #7 g_test_run_suite_internal
    at gtestutils.c line 1727
  • #8 g_test_run_suite_internal
    at gtestutils.c line 1727
  • #9 g_test_run_suite
    at gtestutils.c line 1772
  • #10 main
    at tls-interaction.c line 666

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.
Comment 1 Dan Winship 2012-06-25 12:58:48 UTC
see also bug 674822
Comment 2 Dan Winship 2012-06-25 15:03:41 UTC
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...
Comment 3 Stef Walter 2012-06-28 12:43:18 UTC
Created attachment 217519 [details] [review]
GTlsInteraction: Fix incorrect locking of mutex

* Fix incorrect locking of mutex in g_tls_interaction_invoke_ask_password()
Comment 4 Dan Winship 2012-06-28 12:45:34 UTC
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