Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1362084
| From | Patrick Donnelly <pdonnel3@nd.edu> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Question regarding ptrace work for LInux v3.1 |
| Date | 2016-03-21 20:30 +0100 |
| Message-ID | <rfdGy-1FG-19@gated-at.bofh.it> (permalink) |
| References | <rfc7M-z3-9@gated-at.bofh.it> <rfc7M-z3-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Mar 21, 2016 at 1:47 PM, Oleg Nesterov <oleg@redhat.com> wrote: >> 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? It does not report the SIGSTOP nor the system calls leading up to the PTRACE_EVENT_CLONE (not even the entry into the clone syscall). >> 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. That seems to be the case but it will only report certain events (not syscalls). I have observed PTRACE_EVENT_EXIT and PTRACE_EVENT_CLONE events... Hmm, now that I think about this, it would be necessary to see the initial SIGSTOP (or PTRACE_EVENT_STOP) in order to initiate syscall tracing via PTRACE_SYSCALL. So that does seem to indicate the problem. > 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. The tree of processes being traced do no send any signals but an external process may have. However, I did notice the use of futexes near these clones. Perhaps that may be causing this? > But unless you use PTRACE_SEIZE the same can happen on v3.1 so it seems > there is something else. Okay, it might be that PTRACE_SEIZE fixes it. > It would be nice to have a test-case :/ Unfortunately, I have not yet been able to isolate a test case. Thanks for your help! -- Patrick Donnelly
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: Question regarding ptrace work for LInux v3.1 Oleg Nesterov <oleg@redhat.com> - 2016-03-21 18:50 +0100
Re: Question regarding ptrace work for LInux v3.1 Oleg Nesterov <oleg@redhat.com> - 2016-03-21 20:30 +0100
Re: Question regarding ptrace work for LInux v3.1 Patrick Donnelly <pdonnel3@nd.edu> - 2016-03-21 20:30 +0100
Re: Question regarding ptrace work for LInux v3.1 Oleg Nesterov <oleg@redhat.com> - 2016-03-21 20:40 +0100
Re: Question regarding ptrace work for LInux v3.1 Patrick Donnelly <pdonnel3@nd.edu> - 2016-03-23 15:20 +0100
Re: Question regarding ptrace work for LInux v3.1 Patrick Donnelly <pdonnel3@nd.edu> - 2016-03-21 20:30 +0100
csiph-web