|
From: <sv...@va...> - 2011-10-09 20:03:04
|
Author: florian Date: 2011-10-09 20:58:19 +0100 (Sun, 09 Oct 2011) New Revision: 12130 Log: This patch by Philippe Waroquiers, phi...@sk... 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. Modified: trunk/gdbserver_tests/mcinvokeRU.vgtest Modified: trunk/gdbserver_tests/mcinvokeRU.vgtest =================================================================== --- trunk/gdbserver_tests/mcinvokeRU.vgtest 2011-10-09 08:48:22 UTC (rev 12129) +++ trunk/gdbserver_tests/mcinvokeRU.vgtest 2011-10-09 19:58:19 UTC (rev 12130) @@ -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 |