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
