Re: ptrace attach in multi-threaded processes

On Thu, Jul 14, 2016 at 08:25:37AM +0300, Konstantin Belousov wrote:
> On Wed, Jul 13, 2016 at 01:01:39PM -0700, Mark Johnston wrote:
> > On Wed, Jul 13, 2016 at 10:19:47PM +0300, Konstantin Belousov wrote:
> > > Hmm, I think no, we can not make such change. Issue is, debugger
> > > interface guarantees (at least for single-threaded programs it is
> > > done correctly) that SIGSTOP is noted. In my opinion, it would be the
> > > incompatible API change.
> > 
> > But this guarantee is not honoured in the single-threaded case where
> > PT_ATTACH sends SIGSTOP after another signal is already pending. This
> > other signal will stop the process in ptracestop(), so SIGSTOP will not
> > be reported until after a PT_CONTINUE or PT_DETACH, which seems to
> > violate the interface as you described it. Am I missing some reason
> > that this cannot occur? If not, I'll write a test case for the
> > single-threaded case first.
> 
> Please give me some initial test case, I am fine with single-threaded case.
> I do not think that the mt test would be much different ?

Please see the program here:
https://people.freebsd.org/~markj/ptrace_stop.c

It cheats a bit: it uses SIGSTOP to stop the child before sending a
SIGHUP to it. However, this is just for convenience; note that PT_ATTACH
will result in a call to thread_unsuspend() on the child, so PT_ATTACH's
SIGSTOP will be delivered to a running process. When ptrace attaches,
the child stops and WSTOPSIG(status) == SIGHUP. When ptrace detaches,
the child is left stopped.