Update this test a bit. It's basically flawed though.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8761

diff --git a/helgrind/tests/tc15_laog_lockdel.c b/helgrind/tests/tc15_laog_lockdel.c
index ff0160549ede4f9c2ab7ad82149280e0271794e6..68668b188adaa3be635d0254e1b612fd98181331 100644 (file)
--- a/helgrind/tests/tc15_laog_lockdel.c
+++ b/helgrind/tests/tc15_laog_lockdel.c
@@ -5,8 +5,8 @@
 #include <assert.h>
 
 /* Test that locks, having entered the lock acquisition tracking
-   machinery, are forgotten by it when the memory they reside in
-   becomes inaccessible. */
+   machinery, are forgotten by it when the client does
+   pthread_{mutex,rwlock}_destroy.  2008-Nov-10: see comments below. */
 
 int main ( void )
 {
@@ -38,19 +38,19 @@ int main ( void )
    r = pthread_mutex_unlock( mx1 ); assert(r==0);
    r = pthread_mutex_unlock( mx2 ); assert(r==0);
 
-   /* Free 2 and re-allocate it.  This gives it a new identity, 
-      so a second locking sequence 2 -> 1 should now be OK. */
+   /* De-initialise 2 and re-initialise it.  This gives it a new
+      identity, so a second locking sequence 2 -> 1 should now be OK. */
    fprintf(stderr, 
            "Free 2 and re-allocate it.  This gives it a new identity,\n");
    fprintf(stderr, "so a second locking sequence 2 -> 1 should now be OK.\n");
    pthread_mutex_destroy( mx2 );
-   free(mx2);
-   mx2 = malloc(sizeof(pthread_mutex_t));
-   assert(mx2);
+
+
+
    r = pthread_mutex_init( mx2, NULL ); assert(r==0);
 
-   r = pthread_mutex_lock( mx2 ); assert(r==0); /* error */
-   r = pthread_mutex_lock( mx1 ); assert(r==0);
+   r = pthread_mutex_lock( mx2 ); assert(r==0);
+   r = pthread_mutex_lock( mx1 ); assert(r==0); /* no error */
 
    r = pthread_mutex_unlock( mx1 ); assert(r==0);
    r = pthread_mutex_unlock( mx2 ); assert(r==0);
@@ -66,3 +66,12 @@ int main ( void )
 
    return 0;
 }
+
+/* 2008-Nov-10: I believe this test is flawed and requires further
+   investigation.  I don't think it really tests what it claims to
+   test.  In particular, it still gives the right results if
+   "pthread_mutex_destroy( mx2 );" at line 46 is commented out.  In
+   other words, laog somehow forgets about mx2 so that 2->1 lock
+   sequence at lines 52/3 does not produce a complaint, EVEN WHEN the
+   preceding "pthread_mutex_destroy( mx2 );" is not observed.  I don't
+   know why this is, but it seems highly suspicious to me. */