|
From: <sv...@va...> - 2008-11-10 16:33:39
|
Author: sewardj
Date: 2008-11-10 16:33:29 +0000 (Mon, 10 Nov 2008)
New Revision: 8761
Log:
Update this test a bit. It's basically flawed though.
Modified:
trunk/helgrind/tests/tc15_laog_lockdel.c
Modified: trunk/helgrind/tests/tc15_laog_lockdel.c
===================================================================
--- trunk/helgrind/tests/tc15_laog_lockdel.c 2008-11-10 16:19:21 UTC (rev 8760)
+++ trunk/helgrind/tests/tc15_laog_lockdel.c 2008-11-10 16:33:29 UTC (rev 8761)
@@ -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 @@
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 @@
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. */
|