(try to) avoid tc09_bad_unlock random failure

tc09_bad_unlock fails randomly for the following reason:
Thread 1 is creating a lock in a stack variable and locks it.
It then clones a Thread 2 that will unlock this lock.
The test fails if the Thread 2 unlocks the lock while the
main thread is still just after the clone syscall:
There is no unwind info in this area, and so doing a stacktrace
implies a nasty hack (see hg_main.c evh__pre_thread_ll_create).

There is no such hack when describing the address of the lock
(as there is no logic in the 'normal' stack trace to detect we are
in the clone syscall code).
In such a case, the unwind fail, and the lock address description
lacks the frame nr derived from the captured stack trace.

Adding --fair-sched=yes seems to make a more reproducible test.

Note that the proper solution to all these 'racy helgrind regtests'
would be to add some synchronisations operations between threads
that helgrind does not observe (e.g. using a technique similar to
the pipe big lock) and have correct (but invisible to helgrind) synchronisation
between the threads actions needed for a reproducible regtest.

Not very cheap to develop, --fair-sched=try is cheap and easy
so use that till someone courageous implements non visible synchronisation

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

diff --git a/helgrind/tests/tc09_bad_unlock.vgtest b/helgrind/tests/tc09_bad_unlock.vgtest
index d09a702ecbc653f051b1ef21123cc8d568457e44..c2ec336448ad667d6908439279d637fc7af23058 100644 (file)
--- a/helgrind/tests/tc09_bad_unlock.vgtest
+++ b/helgrind/tests/tc09_bad_unlock.vgtest
@@ -1 +1,2 @@
 prog: tc09_bad_unlock
+vgopts: --fair-sched=try