aboutsummaryrefslogtreecommitdiff
path: root/glibc-2.2.supp
diff options
context:
space:
mode:
authorsewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9>2002-11-13 21:57:52 +0000
committersewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9>2002-11-13 21:57:52 +0000
commitd8acdf25eb7b70bad976dfb9ed843449020b12c3 (patch)
treec05eb9b2d0ec89d582b88129b62017809b533335 /glibc-2.2.supp
parentf912dfc00e99f9a64eb35f3babe52bfa86882fb1 (diff)
downloadvalgrind-d8acdf25eb7b70bad976dfb9ed843449020b12c3.tar.gz
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
Diffstat (limited to 'glibc-2.2.supp')
-rw-r--r--glibc-2.2.supp8
1 files changed, 1 insertions, 7 deletions
diff --git a/glibc-2.2.supp b/glibc-2.2.supp
index 3dbb2bb31..859ed58ae 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)