Re: Question regarding ptrace work for LInux v3.1
From: Oleg Nesterov
Date: Mon Mar 21 2016 - 13:49:12 EST
Hello Patrick,
On 03/18, Patrick Donnelly wrote:
>
> We are currently trying to debug a problem with ptrace that I believe
> was incidentally fixed by you and maybe Tejun Heo in Linux v3.1.
So let me add Tejun and lkml,
> The
> issue is on github [2] but I will describe it here briefly. My hope is
> that you may remember fixing this and a patch may be made for v3.0.
> [An HPC center is using Linux v3.0 which exhibits this.]
Heh, sorry, I can't recall anything related ;)
> The basic problem is that the application we are tracing spawns
> threads which **sometimes** are not traced (or lost). For Linux v3.0,
> we are using PTRACE_ATTACH and the PTRACE_O_TRACE(CLONE|FORK|VFORK)
> options to follow children [3]. The problem we see is that we will
> receive a PTRACE_EVENT_CLONE event that a thread is created but we
> receive no other events for the thread.
IOW, the new thread do not report SIGSTOP injected by implicit attach?
> What's worse is that the
> thread eventually "comes back" via a PTRACE_EVENT_CLONE when it clones
> its own thread.
OK, so at least the new child is traced too, and it also has PT_TRACE_*
flags copied from its parent.
> Do you recall fixing anything for v3.1 that might cause this problem?
No. I do not see how the new tracee can miss that SIGSTOP/TIF_SIGPENDING.
To clarify, the usage of SIGSTOP in ptrace was always buggy by design.
For example, SIGCONT from somewhere can remove the pending (and not yet
reported) SIGSTOP, and this _can_ explain the problem you hit.
But unless you use PTRACE_SEIZE the same can happen on v3.1 so it seems
there is something else.
It would be nice to have a test-case :/
Oleg.
> [1] http://ccl.cse.nd.edu/software/parrot/
> [2] https://github.com/cooperative-computing-lab/cctools/issues/1207
> [3] https://github.com/cooperative-computing-lab/cctools/blob/f82288167b1b5abb836b1d9b8135c98f71ed90f6/parrot/src/tracer.c#L91-L128
>
> --
> Patrick Donnelly