apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <phi...@codematters.co.uk>
Subject pthread_mutex_unlock called on unlocked mutex
Date Thu, 20 Jun 2002 00:53:57 GMT
Hello

Running the latest valgrind on the Subversion executables generates
errors that are caused by APR.

==4022== pthread_mutex_unlock: mutex is not locked
==4022==    at 0x404EE4BF: (within /usr/lib/valgrind/libpthread.so)
==4022==    by 0x403B7043: thread_mutex_cleanup (thread_mutex.c:67)
==4022==    by 0x403B9CD2: run_cleanups (apr_pools.c:1940)
==4022==    by 0x403B93B9: pool_clear_debug (apr_pools.c:1361)

These are caused by the Unix implementation of thread_mutex_cleanup
calling pthread_mutex_unlock when a mutex is destroyed.

APR does not use anything like PTHREAD_MUTEX_ERRORCHECK.  It is
strictly undefined to call pthread_mutex_unlock on a mutex that is not
locked, or to call pthread_mutex_unlock on a mutex that is locked by
another thread.

Attempting to unlock an unlocked mutex is probably harmless on some
(all?) pthread implementations, but I don't think it's good practice
to do it.  What benefit can there be?  If there is a reason for doing
it, then such use of undefined behaviour should be documented.  As it
currently stands, an application that quite properly ensures that its
mutexes are not in use when they are destroyed unwittingly invokes
undefined behaviour.

-- 
Philip

Mime
View raw message