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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 11 Apr 2008 01:12:05 +0200, Roland McGrath wrote:
> > As the shell already did WAITPID on the process and ate the SIGSTOP
> > notification so there is no other notification left there for GDB.
> > A process already stopped does not generate another SIGSTOP during
> > PTRACE_ATTACH as signals never count.
> 
> To be pedantic about it: a SIGSTOP is generated, but causes no wakeup or
> delivery for ptrace to see (because it's already stopped).  You can see
> the SIGSTOP pending in /proc/pid/status.  Generating a SIGCONT clears
> any pending stop signals, so normally it's as if it never existed.  But,
> I think if you were to do PTRACE_CONT,pid,0,0 you would make it wake up,
> dequeue the new SIGSTOP and then report to you for wait/SIGCHLD.  And
> since PTRACE_CONT would give ESRCH if it weren't stopped yet, you might
> be able to do PTRACE_ATTACH;PTRACE_CONT;wait reliably.  But don't hold
> me to it.

There is a race if:
* inferior was not stopped (a regular running process)
* PTRACE_ATTACH
* sleep a bit
* PTRACE_CONT
  - Here we do not get ESRCH but it behaves as a regular continuation of the
    inferior - as we would do PTRACE_ATTACH;waitpid;PTRACE_CONT.
    nonESRCH does not mean the inferior was stopped before PTRACE_ATTACH.

So IMO we must first check if the inferior is stopped in `/proc/PID/status'
which is already racy in respect to later PTRACE_ATTACH and the other ops.


Regards,
Jan