Merge patch from JeremyF:
22-mutex-destroy-unlock:
It seems that glibc assumes in its internal use of pthreads that
destroying a lock implicity unlocks it. This patch handles this case
so that lock ownership tracking is accurate.
Also handles the case of the dyanmic linker wanting to do locking
before Valgrind has started up. vg_libpthread now implements toy
lock/unlock functions to keep it happy and leave the locks in a
sensible state. Implements some untested code to handle the case where
a lock is taken before Valgrind is running but released afterwards.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1297 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/glibc-2.2.supp b/glibc-2.2.supp
index 3dbb2bb..859ed58 100644
--- a/glibc-2.2.supp
+++ b/glibc-2.2.supp
@@ -138,6 +138,7 @@
#}
#-------- Threading bugs?
+# glibc 'knows' that destroying a locked mutex will unlock it
{
pthread_error/__pthread_mutex_destroy/__closedir
core:PThread
@@ -161,13 +162,6 @@
fun:_IO_funlockfile
}
-{
- __pthread_mutex_unlock/__register_frame_info
- core:PThread
- fun:__pthread_mutex_unlock
- fun:__register_frame_info
-}
-
# even more glibc suppressions ?
{
libc-2.2.4.so/libc-2.2.4.so/libc-2.2.4.so(Cond)