You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Philip Martin <ph...@codematters.co.uk> on 2002/06/20 02:53:57 UTC
pthread_mutex_unlock called on unlocked mutex
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
Re: pthread_mutex_unlock called on unlocked mutex
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Jun 20, 2002 at 01:53:57AM +0100, Philip Martin wrote:
> 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.
Committed, thanks.
-aaron
Re: pthread_mutex_unlock called on unlocked mutex
Posted by Aaron Bannert <aa...@clove.org>.
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.
-aaron