GNOME Bugzilla – Bug 152009
missing testcase in g_mutex_trylock_posix_impl
Last modified: 2011-02-18 16:09:12 UTC
one program that's known to fail is beep-media-player on FreeBSD using libpthread as Posix Threading Library. Simply start beep-media-player and it will SIGABORT because of an "error" in g_thread_mutex_trylock_posix_impl I have managed to track it down to the following details: gthread-posix.c in my case uses the following appropriate #defines (because of G_THREADS_IMPL_POSIX) # define mutexattr_default NULL FreeBSD's libpthread/libthr will assume a default PTHREAD_MUTEX_ERRORCHECK mutexattr in this case for newly created mutexes. g_posix_mutex_trylock_posix_impl calls the pthread_mutex_trylock function and checks for a return value of EBUSY and eventualy lets the program ABORT if this is not the case. FreeBSD's libpthread/libthr implementation however states that according to POSIX specification mutexes should return EDEADLK if a recursive lock is detected. FreeBSD's libpthread and libthr threading libraries do so ... libc_r has the same comment but doesn't implement it as such. This explains why applying a libmap.conf redirecting libpthread to libc_r makes affected applications work. In case people are not familair with FreeBSD's libmap functionality, it basically allows us to let the linked ld "redirect" shared libraries. As a test-case i changed the check on the return value of the pthread_mutex_trylock function to not only check for EBUSY but also for EDEADLK and this makes the failing application now work as expected. Confirmation that this would be the correct thing to do would be appreciated. If this is indeed an error on glib's behalf this could be a potential problem for any threaded application that wishes to use glibs' threading functions. If this is a problem with the main application faultily using these glib-threading functions (and henceforth created the EDEADLK situation in the first place) do not hesitate to say so ... and i shall try to bring this issue to their attention.
doesn't getting EDEADLK mean the app is irretrievably buggy, since on most platforms, it won't be a errorcheck mutex? If you trylock with a non-errorcheck mutex in the thread that already holds the lock, you get undefined behavior
Ok ... i decided to check the sources of beep media player to see if i could find out which statement is causing the actual EDEADLK in the first place ... and i think i have found the winner .... in the skin loading code there is the following three lines of code skin_lock(skin); error = skin_load_nolock(skin, path, FALSE); skin_unlock(skin); skin_lock completes successfuly now inside the skin_load_nolock function there is the following statement which obviously functions as an assertion to make sure the lock has indeed been acquired. REQUIRE_LOCK(skin->lock); which uses the following macro definition # define REQUIRE_LOCK(m) G_STMT_START { \ if (g_mutex_trylock(m)) { \ g_critical(G_STRLOC ": Mutex not locked!"); \ g_mutex_unlock(m); \ } \ } G_STMT_END And voila ... there is our offending g_mutex_trylock call Obviously trying to relock the already locked mutex generating the observed EDEADLK instead of EBUSY because the default mutexattr is an ERRORCHECKING mutex.
The following discussion hopefully sheds some more details concerning FreeBSD's interpretation of the POSIX spec and implementation descisions ... (note that FreeBSD's pthread_mutex_trylock manpage fails to actually mention the EDEADLK situation) http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html
There has been a recent discussion regarding this particular issue and the outcome has been that in occardance with the Open Group regarding interpretation of the POSIX standard for the pthread_mutex_trylock function the FreeBSD implementation of said function has been altered (on the 6.0-CURRENT branch for now with a merge to the STABLE branches scheduled 1 month later). This should render my proposed change unnessesary. For more details check the following mailinglist archive-tread. http://lists.freebsd.org/pipermail/cvs-src/2004-October/034445.html