Re: PTRACE_DETACH without stop [Re: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT]

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

Hi Tejun,

On Mon, 16 May 2011 11:01:25 +0200, Tejun Heo wrote:
> On Sun, May 15, 2011 at 07:39:40PM +0200, Jan Kratochvil wrote:
> > #include <unistd.h>
> > #include <sys/wait.h>
> > #include <sys/ptrace.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > static int status;
> > static pid_t child;
> > void
> > handler (int signo)
> > {
> >   puts ("PASS");
> >   exit (0);
> > }
> > /* Ensure CHILD is stopped even if it is running now - for PTRACE_DETACH.  */
> > void
> > stop_child_for_detach (void)
> > {
> >   kill (child, SIGCONT);	/* To be PTRACE_INTERRUPT in the future.  */
> >   /* The problem - here a signal may get lost.  */
> >   wait (&status);
> > }
> > int
> > main (void)
> > {
> >   child = fork ();
> >   switch (child)
> >     {
> >     case 0:
> >       signal (SIGUSR2, handler);
> >       ptrace (PTRACE_TRACEME, 0, NULL, NULL);
> >       raise (SIGUSR1);
> >       puts ("FAIL");
> >       exit (1);
> >     default:
> >       wait (&status);
> >       /* Sent by arbitrary external program.  */
> >       kill (child, SIGUSR2);
> >       /* Comment out for PTRACE_DETACH not requiring stopped tracee.  */
> > #if 1
> >       ptrace (PTRACE_CONT, child, NULL, NULL);
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> You can lose signal here.

Not here but there should be PTRACE_CONT in stop_child_for_detach.

That SIGUSR1 was intended to be dropped - it was there just to get stopped by
PTRACE_TRACEME.


> You must check which trap happened why and then take action accordingly.
> Argh... we really need better documentation of ptrace behaviors and traps.

We could misunderstand each other here.  Sure I know where is the problem.
Just demonstration that writing correct `stop_child_for_detach' is not easy
and naive programmer may write it looking right and working right during
development but in fact it will break debuggees in corner cases.


> Nope.  What userland is currently dealing with isn't that type of
> conditions.  It's dealing with nasty side effects of implied and
> required signals, which will be removed with the new interface.

They won't as there will be new INTERRUPT event and when one wants to trap it
one has to deal with various signals coming before or after it.


> Those attach/detach sync points are currently in the kernel and wouldn't
> change with the proposed updates.  You're suggesting to remove them.

I am suggesting not to introduce the existing pain into new API.


Thanks,
Jan