This patch by Philippe Waroquiers, philippe.waroquiers@skynet.be
replaces r12124. His analysis of the testcase failure:
I think I understand what is happening: even if the ptrace invoker functionality
is not needed, the timeout to invoke might expire, which then leads
to a message produced by vgdb if ptrace is restricted by the kernel.
I think the best way to fix this is to add the option --max-invoke-ms=0 to vgdb.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12130 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/gdbserver_tests/mcinvokeRU.vgtest b/gdbserver_tests/mcinvokeRU.vgtest
index 825ca56..44a9e5f 100644
--- a/gdbserver_tests/mcinvokeRU.vgtest
+++ b/gdbserver_tests/mcinvokeRU.vgtest
@@ -1,13 +1,14 @@
# test that vgdb can invoke a process when all threads are in Runnable or Yielding mode
# If the test goes wrong, it might consume CPU during a long time.
-prereq: ! test -e "/proc/sys/kernel/yama/ptrace_scope" || [ "`cat /proc/sys/kernel/yama/ptrace_scope`" = "0" ]
prog: sleepers
args: 1 0 1000000000 B-B-B-B-
vgopts: --tool=memcheck --vgdb=yes --vgdb-prefix=./vgdb-prefix-mcinvokeRU
stderr_filter: filter_make_empty
# as the Valgrind process is always busy, we do not need the vgdb.ptraceinvoker prereq.
+# We even disable ptrace invoker to avoid spurious attach error message
+# on kernels where ptrace is restricted.
progB: invoker
-argsB: 10 --vgdb-prefix=./vgdb-prefix-mcinvokeRU --wait=60 -c v.wait 0
+argsB: 10 --vgdb-prefix=./vgdb-prefix-mcinvokeRU --max-invoke-ms=0 --wait=60 -c v.wait 0
# if the --wait is not enough, the test will fail or block.
stdoutB_filter: filter_memcheck_monitor
stderrB_filter: filter_vgdb