Lines Matching refs:tracee

16 debugged. Therefore, "tracee" always means "(one) thread", never "a
18 a specific tracee using ptrace(PTRACE_foo, pid, ...), where pid is a
21 After attachment, each tracee can be in two states: running or stopped.
23 There are many kinds of states when tracee is stopped, and in ptrace
27 In this document, any stopped state in which tracee is ready to accept
38 not a ptrace-stop (because tracer can't query tracee status such as
39 register contents, cannot restart tracee etc) but the notification
44 tracee only), and only after it is injected by tracer (or after it was
55 Tracer can kill a tracee with ptrace(PTRACE_KILL, pid, 0, 0). This
61 When tracee executes exit syscall, it reports its death to its tracer.
64 When any thread executes exit_group syscall, every tracee in its thread
72 Tracer cannot assume that ptrace-stopped tracee exists. There are many
73 scenarios when tracee may die while stopped (such as SIGKILL).
75 ptrace operation. Unfortunately, the same error is returned if tracee
77 tracee), or if it is not traced by process which issued ptrace call.
79 ESRCH as "tracee died unexpectedly" only if it knows that tracee has
81 that waitpid(WNOHANG) will reliably report tracee's death status if
83 IOW: tracee may be "not yet fully dead" but already refusing ptrace ops.
85 Tracer can not assume that tracee ALWAYS ends its life by reporting
93 When running tracee enters ptrace-stop, it notifies its tracer using
95 tracee to stop. Most of this document assumes that tracer waits with:
111 of the tracee.
115 notification. Example: kill(tracee, SIGKILL); waitpid(tracee, &status,
138 If tracer doesn't suppress the signal, it passes signal to tracee in
155 tracee with
174 was injected to the tracee.
178 signal-delivery-stop, restarts tracee with ptrace(PTRACE_rest, pid, 0,
180 ignored and tracee continues to run.
186 not be executed in the tracee, if such handler is installed). In fact,
190 tracee after it was sent.
208 tracee only), and only after it is injected by tracer (or after it was
211 tracee reports its group-stop separately to corresponding tracer.
225 possible, such as ESRCH "no such process" if SIGKILL killed the tracee).
227 As of kernel 2.6.38, after tracer sees tracee ptrace-stop and until it
228 restarts or kills it, tracee will not run, and will not send
233 signals: if tracer restarts tracee after group-stop, SIGSTOP is
234 effectively ignored: tracee doesn't remain stopped, it runs. If tracer
235 doesn't restart tracee before entering into next waitpid, future
242 If tracer sets TRACE_O_TRACEfoo options, tracee will enter ptrace-stops
251 When tracee is continued after this, it will wait for child to
260 vfork/clone+CLONE_VFORK, but after vfork child unblocked this tracee by
272 (unlike when "real" exit happens). The tracee is still alive, it needs
281 If tracee was restarted by PTRACE_SYSCALL, tracee enters
283 restarts it with PTRACE_SYSCALL, tracee enters syscall-exit-stop when
288 Other possibilities are that tracee may stop in a PTRACE_EVENT stop,
320 always followed by syscall-exit-stop, PTRACE_EVENT stop or tracee's
337 Most ptrace commands (all except ATTACH, TRACEME, KILL) require tracee
340 When tracee is in ptrace-stop, tracer can read and write data to tracee
341 using informational commands. They leave tracee in ptrace-stopped state:
356 ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_flags) affects one tracee.
361 Another group of commands makes ptrace-stopped tracee run. They have
367 SYSEMU_SINGLESTEP. If tracee is in signal-delivery-stop, sig is the
377 see tracee enter signal-delivery-stop with other signal(s) first! The
386 the tracee, as described in "signal injection and suppression" section.
389 tracee. It continues to run (doesn't enter ptrace-stop). A common
401 Detaching of tracee is performed by ptrace(PTRACE_DETACH, pid, 0, sig).
402 PTRACE_DETACH is a restarting operation, therefore it requires tracee
403 to be in ptrace-stop. If tracee is in signal-delivery-stop, signal can
406 If tracee is running when tracer wants to detach it, the usual solution
408 thread), wait for tracee to stop in signal-delivery-stop for SIGSTOP
411 tracee may enter other ptrace-stops and needs to be restarted and
413 be sure that tracee is not already ptrace-stopped, because no signal
416 ??? Describe how to detach from a group-stopped tracee so that it
421 currently buggy, but "as planned" behavior is to leave tracee stopped
422 and waiting for SIGCONT. If tracee is restarted from
436 (on which tracee - leader? execve-ing one?).
438 The execve-ing tracee changes its pid while it is in execve syscall.
440 calls, is tracee's tid). That is, pid is reset to process id, which
449 tracer), during execve it will appear as if it has become a tracee of
450 the tracer of execve'ing tracee. All these effects are the artifacts of
460 guaranteed that except this tracee and thread group leader, no other
465 data structure, one which describes single still running tracee, with
468 Currently, there is no way to retrieve former pid of execve-ing tracee.
470 may be unable to know which tracee  execve-ed and therefore no longer
488 tracee, kernel delivers an extra SIGTRAP to tracee after execve syscall
496 to the tracee (if SIGTRAP is set to SIG_DFL, it is a killing signal).