apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: pthread_mutex_unlock called on unlocked mutex
Date Thu, 20 Jun 2002 01:12:29 GMT
On Thu, Jun 20, 2002 at 01:53:57AM +0100, Philip Martin wrote:
> 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.

Sander asked me to look at this and unless someone objects, I'm going
to remove it.


View raw message