This is the mail archive of the
mailing list for the GDB project.
Re: [patch] Fix Linux attach to signalled/stopped processes
> Date: Wed, 27 Jun 2007 08:52:03 +0200
> From: Jan Kratochvil <email@example.com>
> On Wed, 27 Jun 2007 00:54:54 +0200, Mark Kettenis wrote:
> > This is what I get on OpenBSD:
> > $ ./ptrace-test
> > .assertion "!WIFSIGNALED (status)" failed: file "ptrace-test.c", line 122, function "main"
> > Abort trap (core dumped)
> > This is sort of odd,
> Thanks for the test - it is now confirmed the code is not crossplatform and
> different hacks may be needed on different ptrace(2)-using OSes.
> OK, going to move it to linux-nat.c.
> > but then your test program has a serious problem.
> > It doesn't wait(2) after ptrace(PT_ATTACH, ...). That's asking for trouble.
> It does wait(2) right after a preventive `PT_CONT (SIGSTOP)' as otherwise
> wait(2) would hang if the original process was already stopped ...
That's a kernel bug in my book; wait(2) should always report a SIGSTOP
after a PT_ATTACH as soon as the traced process has been stopped. If
the process was already stopped, wait(2) should simply report that
> > > How does currently GDB behave there while attaching to a SIGSTOPped process?
> > I don't think it matters whether the process is stopped or not.
> ... the same way the current GDB hangs. SIGSTOP is already delivered before
> and the new SIGSTOP from PTRACE_ATTACH does not stack as SIGSTOP is already
> active. If the original SIGSTOP was already wait(2)ed by the pre-ptrace(2)
> parent the new ptrace(2)-parent (the debugger) will not get the new SIGSTOP
> caught and thus wait(2) hangs for it.
> [ Info originally from Roland McGrath. ]
So it seems that Linux completely ignores SIGSTOP if a process is
already stopped. That's the right thing to do for "normal" processes,
but not ok for traced processes. Looks like fixing that would solve a
lot of problems. Wouldn't surprise me if that would also make lots of
the workarounds we put in for debugging multi-threaded programs