Re: [patch] Fix Linux attach to signalled/stopped processes

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 27 Jun 2007 08:52:03 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.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
SIGSTOP immediately.

> > > 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
unnecessary.

Mark