|
From: Christian B. <bor...@de...> - 2011-11-08 08:31:13
|
On 07/11/11 22:17, Philippe Waroquiers wrote:
> Note: I just have one problem : I did one build + regtest on this computer, and had drd running on
> annotate_hbefore that took about one hour of cpu (then I killed it).
> gcc compile farm highly recommends to avoid such looping tests (so, I will put a ulimit
> in cpu when launching the nightly test).
There is probably more than one problem with this testcase, but I am at least aware of one
problem that will hit you on virtualized/loaded systems if the overall load is too high:
this code
[...]
void* thread_fn1 ( void* arg )
{
UWord* w = (UWord*)arg;
delay500ms(); // ensure t2 gets to its wait first
[...]
does not ensure that t2 gets to its wait reliably. Its just very likely, but 500ms can still
be too short, if the guest scheduling puts t2 on a cpu which was not scheduled by a busy
hypervisor or if the system itself is loaded. A thread being runnable does not mean that it
will really run.
A potential fix for the endless loop might be
--- valgrind-upstream.orig/helgrind/tests/annotate_hbefore.c
+++ valgrind-upstream/helgrind/tests/annotate_hbefore.c
@@ -8,6 +8,7 @@
#include <pthread.h>
#include <stdio.h>
#include <assert.h>
+#include <signal.h>
#include "../../helgrind/helgrind.h"
@@ -294,6 +295,7 @@ int main ( void )
r= pthread_create( &t2, NULL, &thread_fn2, (void*)&w ); assert(!r);
r= pthread_join( t1, NULL ); assert(!r);
- r= pthread_join( t2, NULL ); assert(!r);
+ /* there is a race on busy systems, ensure to exit */
+ r= pthread_kill( t2, SIGKILL);
return 0;
}
but this can result in a test case failure if the race triggers.
At least it does not break the test suite
Christian
|