[PATCH] ptrace-tests: fix step-fork.c on powerpc for ptrace-utrace
Instead of using fork(), call syscall(__NR_fork) in step-fork.c
to avoid looping on powerpc arch in libc.
Signed-off-by: Veaceslav Falico vfal...@redhat.com
---
--- ptrace-tests/tests/step-fork.c 2009-12-01 17:17:14.0 +0100
+++ ptrace-tests/tests/step-fork.c 2009-12-01 17:25:12.0 +0100
@@ -29,6 +29,7 @@
#include unistd.h
#include sys/wait.h
#include string.h
+#include sys/syscall.h
#include signal.h
#ifndef PTRACE_SINGLESTEP
@@ -78,7 +79,12 @@ main (int argc, char **argv)
sigprocmask (SIG_BLOCK, mask, NULL);
ptrace (PTRACE_TRACEME);
raise (SIGUSR1);
- if (fork () == 0)
+
+ /*
+ * We can't use fork() directly because on powerpc it loops inside libc
on
+ * ptrace over utrace. See http://lkml.org/lkml/2009/11/28/11
+ */
+ if (syscall(__NR_fork) == 0)
{
read (-1, NULL, 0);
_exit (22);
Re: [PATCH] ptrace-tests: fix step-fork.c on powerpc for ptrace-utrace
On Tue, Dec 01, 2009 at 05:37:48PM +0100, Veaceslav Falico wrote:
- if (fork () == 0)
+
+ /*
+ * We can't use fork() directly because on powerpc it loops inside libc
on
+ * ptrace over utrace. See http://lkml.org/lkml/2009/11/28/11
+ */
+ if (syscall(__NR_fork) == 0)
{
read (-1, NULL, 0);
_exit (22);
Sorry, the comment is just wrong. I'll resend the patch in several minutes.
--
Veaceslav
[PATCH v2] ptrace-tests: fix step-fork.c on powerpc for ptrace-utrace
Instead of using fork(), call syscall(__NR_fork) in step-fork.c
to avoid looping on powerpc arch in libc.
Signed-off-by: Veaceslav Falico vfal...@redhat.com
---
--- a/ptrace-tests/tests/step-fork.c2009-12-01 17:17:14.0 +0100
+++ b/ptrace-tests/tests/step-fork.c2009-12-01 18:35:15.0 +0100
@@ -29,6 +29,7 @@
#include unistd.h
#include sys/wait.h
#include string.h
+#include sys/syscall.h
#include signal.h
#ifndef PTRACE_SINGLESTEP
@@ -78,7 +79,12 @@ main (int argc, char **argv)
sigprocmask (SIG_BLOCK, mask, NULL);
ptrace (PTRACE_TRACEME);
raise (SIGUSR1);
- if (fork () == 0)
+
+ /*
+* Can't use fork() directly because on powerpc it loops inside libc
under
+* PTRACE_SINGLESTEP. See
http://marc.info/?l=linux-kernelm=125927241130695
+*/
+ if (syscall(__NR_fork) == 0)
{
read (-1, NULL, 0);
_exit (22);
Re: utrace-ptrace gdb testsuite tesults
On Wed, Nov 25, 2009 at 01:17:15PM -0800, Roland McGrath wrote: That's certainly good to hear. If you are pretty confident about that, then I am quite happy to consider nonregression on all of ptrace-tests the sole gating test for kernel changes. We just don't want to wind up having other upstream reviewers notice a regression using gdb that we didn't notice before we submitted a kernel change. I've just done 'make check' twice on unpatched kernel, and found that the results are not stable: --- gdb.sum 2009-11-27 09:54:14.0 +0100 +++ gdb.sum22009-11-27 10:51:42.0 +0100 @@ -1,4 +1,4 @@ -Test Run By root on Thu Nov 26 18:52:09 2009 +Test Run By root on Fri Nov 27 09:54:33 2009 Native configuration is i686-pc-linux-gnu === gdb tests === @@ -3537,12 +3537,12 @@ PASS: gdb.base/foll-fork.exp: unpatch ch PASS: gdb.base/foll-fork.exp: unpatch child, catch fork PASS: gdb.base/foll-fork.exp: unpatch child, breakpoint at exit call PASS: gdb.base/foll-fork.exp: unpatch child, set follow child -FAIL: gdb.base/foll-fork.exp: unpatch child, unpatched parent breakpoints from child (timeout) +PASS: gdb.base/foll-fork.exp: unpatch child, unpatched parent breakpoints from child PASS: gdb.base/foll-fork.exp: explicit parent follow, set tcatch fork PASS: gdb.base/foll-fork.exp: explicit parent follow, tcatch fork PASS: gdb.base/foll-fork.exp: set follow parent PASS: gdb.base/foll-fork.exp: set follow parent, tbreak -PASS: gdb.base/foll-fork.exp: set follow parent, hit tbreak +FAIL: gdb.base/foll-fork.exp: (timeout) set follow parent, hit tbreak PASS: gdb.base/foll-fork.exp: set follow parent, cleanup Running ./gdb.base/foll-vfork.exp ... PASS: gdb.base/foll-vfork.exp: set verbose @@ -12499,7 +12499,7 @@ PASS: gdb.mi/mi-nsmoribund.exp: thread s PASS: gdb.mi/mi-nsmoribund.exp: resume all, thread specific breakpoint PASS: gdb.mi/mi-nsmoribund.exp: hit thread specific breakpoint PASS: gdb.mi/mi-nsmoribund.exp: thread state: all running except the breakpoint thread -PASS: gdb.mi/mi-nsmoribund.exp: resume all, program exited normally +FAIL: gdb.mi/mi-nsmoribund.exp: unexpected stop Running ./gdb.mi/mi-nsthrexec.exp ... PASS: gdb.mi/mi-nsthrexec.exp: successfully compiled posix threads test case PASS: gdb.mi/mi-nsthrexec.exp: breakpoint at main @@ -14507,7 +14507,7 @@ PASS: gdb.threads/watchthreads2.exp: bre PASS: gdb.threads/watchthreads2.exp: all threads started PASS: gdb.threads/watchthreads2.exp: watch x PASS: gdb.threads/watchthreads2.exp: set var test_ready = 1 -KFAIL: gdb.threads/watchthreads2.exp: gdb can drop watchpoints in multithreaded app (PRMS: gdb/10116) +PASS: gdb.threads/watchthreads2.exp: all threads incremented x Running ./gdb.threads/watchthreads.exp ... PASS: gdb.threads/watchthreads.exp: successfully compiled posix threads test case PASS: gdb.threads/watchthreads.exp: watch args[0] @@ -14672,7 +14672,7 @@ UNSUPPORTED: gdb.xml/tdesc-xinclude.exp: === gdb Summary === # of expected passes 13854 -# of unexpected failures 75 +# of unexpected failures 76 # of expected failures 43 # of untested testcases7 # of unsupported tests 59 -- Veaceslav
Re: powerpc: fork stepping (Was: [RFC, PATCH 0/14] utrace/ptrace)
On Thu, Nov 26, 2009 at 06:25:24PM +0100, Oleg Nesterov wrote:
On 11/26, Oleg Nesterov wrote:
On 11/26, Ananth N Mavinakayanahalli wrote:
step-fork: step-fork.c:56: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 17325 Aborted ${dir}$tst
FAIL: step-fork
Good to know, thanks again Ananth.
I'll take a look. Since I know nothing about powerpc, I can't
promise the quick fix ;)
The bug was found by code inspection, but the fix is not trivial
because it depends on arch/, and it turns out the arch-independent
fix in
ptrace-copy_process-should-disable-stepping.patch
http://marc.info/?l=linux-mm-commitsm=125789789322573
doesn't work.
Just noticed the test-case fails in handler_fail(). Most probably
this means it is killed by SIGALRM because either parent or child
hang in wait(). Perhaps we have another (ppc specific?) bug, but
currently I do not understand how this is possible, this should
not be arch-dependent.
I can confirm that we have another bug on ppc arch. The test case below
is spinning forever,
#include stdio.h
#include unistd.h
#include signal.h
#include sys/ptrace.h
#include sys/wait.h
#include assert.h
int main(void)
{
int pid, status;
if (!(pid = fork())) {
assert(ptrace(PTRACE_TRACEME) == 0);
kill(getpid(), SIGSTOP);
if (!fork())
return 0;
printf(fork passed..\n);
return 0;
}
for (;;) {
assert(pid == wait(status));
if (WIFEXITED(status))
break;
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
}
printf(Parent exit.\n);
return 0;
}
it doesn't hang, the parent is spinning around for, the test case
isn't printing anything. Seems like fork() can't complete under
PTRACE_SINGLESTEP.
--
Veaceslav
