ptrace and threads

ptrace and threads

[Charles P. Wright]

Hello,

Is there a proper, non-racy, way to hand a ptraced child off from one
tracing process to another tracing process?

Specifically, I want to architect my tracing application such that each
traced process is traced by a separate thread.

For non-threaded applications, I was adding CLONE_STOPPED to the
clone(2) flags of the child.  This way, when the child process started
up, it would be stopped and a new tracing thread could PTRACE_ATTACH to
it before any system calls were executed.  Unfortunately, this method
doesn't seem to work for threaded traced processes.  The reason is that
the SIGSTOP may be delivered to the traced parent instead of the traced
child, because signal handlers are shared.

My next thought was to add CLONE_PTRACE to the flags.  This way, the
tracing process gets signaled via wait before the child begins to
execute.  The problem now is that I need to the have a separate
monitoring thread take control of the child.  I tried using
ptrace(PTRACE_DETACH, ..., ..., SIGSTOP) in the original tracing process
to stop the process after the fork, followed by a ptrace(PTRACE_ATTACH)
in the new tracing process.  Again, the STOP signal doesn't seem to be
reliably delivered (and the man page says you can't use SIGSTOP as an
argument to PTRACE_CONT and that PTRACE_DETACH's semantics match those
of PTRACE_CONT).

Thank you,
Charles

P.S. I am not subscribed to lkml, so please Cc: me on replies.

Re: ptrace and threads

[Jeff Dike]

On Wed, Feb 15, 2006 at 02:14:01PM -0500, Charles P. Wright wrote:
> I tried using
> ptrace(PTRACE_DETACH, ..., ..., SIGSTOP) in the original tracing process
> to stop the process after the fork, followed by a ptrace(PTRACE_ATTACH)
> in the new tracing process.

This has worked for me in the past.  The one tricky bit is that the process
needs a SIGCONT before it will run again (and appear to be active under
the new tracer).

				Jeff

Re: ptrace and threads

[Daniel Jacobowitz]

On Wed, Feb 15, 2006 at 02:14:01PM -0500, Charles P. Wright wrote:
> Is there a proper, non-racy, way to hand a ptraced child off from one
> tracing process to another tracing process?
> 
> Specifically, I want to architect my tracing application such that each
> traced process is traced by a separate thread.
> 
> For non-threaded applications, I was adding CLONE_STOPPED to the
> clone(2) flags of the child.  This way, when the child process started
> up, it would be stopped and a new tracing thread could PTRACE_ATTACH to
> it before any system calls were executed.  Unfortunately, this method
> doesn't seem to work for threaded traced processes.  The reason is that
> the SIGSTOP may be delivered to the traced parent instead of the traced
> child, because signal handlers are shared.
> 
> My next thought was to add CLONE_PTRACE to the flags.  This way, the
> tracing process gets signaled via wait before the child begins to
> execute.  The problem now is that I need to the have a separate
> monitoring thread take control of the child.  I tried using
> ptrace(PTRACE_DETACH, ..., ..., SIGSTOP) in the original tracing process
> to stop the process after the fork, followed by a ptrace(PTRACE_ATTACH)
> in the new tracing process.  Again, the STOP signal doesn't seem to be
> reliably delivered (and the man page says you can't use SIGSTOP as an
> argument to PTRACE_CONT and that PTRACE_DETACH's semantics match those
> of PTRACE_CONT).

You didn't say what kernel version you're concerned with.  There have
definitely been fixes in this area in the last year.  If you're using a
current kernel and PTRACE_DETACH can't leave the thread stopped, please
let us know.  I'd have expected the CLONE_STOPPED approach to work too.

However, I also recall some trouble with having one thread running
ptraced while another thread is not ptraced, where SIGTRAP would be
delivered to the wrong thread.  So there may still be trouble.

-- 
Daniel Jacobowitz
CodeSourcery