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
