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

diff --git a/gdbserver_tests/mcinvokeRU.vgtest b/gdbserver_tests/mcinvokeRU.vgtest
index 825ca56d087c05c64eba0ba3aaf821c071fbcb9f..44a9e5f851b23b154dee3d4cdaf9fa1a10363ef2 100644 (file)
--- 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