Re: FYI: fix 2 tests when glibc debuginfo is installed

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 25 October 2011 19:30:22, Oleg Nesterov wrote:
> On 10/25, Pedro Alves wrote:
> >
> > On Tuesday 25 October 2011 18:32:49, Oleg Nesterov wrote:

> > > But, compared to the old kernels, the tracee "remembers" the
> > > fact it was stopped, and it will stop again after DETACH. Unless SIGCONT
> > > in between.
> >
> > What about PTRACE_CONT in between (no SIGCONT)?  Does it make the
> > kernel "forget" the fact that the child was stopped before?
> 
> No,

Ah, cool.

> > If not, what happens if the ptracer dies while its child
> > is PTRACE_CONT'ed, and the child was stopped at PTRACE_ATTACH time?
> 
> This doesn't differ from the explicit PTRACE_DETACH.
> 
> Actually, this is very simple. We have the per-process (_not_
> per thread/tracee) flag, SIGNAL_STOP_STOPPED. It means that this
> thread group is stopped (OK, it is not that simple, but we can ignore
> details). ptrace can never set/clear this flag. In particular it
> is still set after PTRACE_CONT or whatever resumes the tracee.
> Only SIGCONT clears SIGNAL_STOP_STOPPED.
> 
> Now, __ptrace_unlink() (called by PTRACE_DETACH or by the dying
> tracee) checks SIGNAL_STOP_STOPPED, if it is set we ask the tracee
> to stop again.

Thanks!  All makes sense now.

-- 
Pedro Alves