1PTRACE(2) Linux Programmer's Manual PTRACE(2)
2
6 ptrace - process trace
7
9 #include <sys/ptrace.h>
10 long ptrace(enum __ptrace_request request, pid_t pid,
12 void *addr, void *data);
13
15 The ptrace() system call provides a means by which one process (the
16 "tracer") may observe and control the execution of another process (the
17 "tracee"), and examine and change the tracee's memory and registers.
18 It is primarily used to implement breakpoint debugging and system call
19 tracing.
20 A tracee first needs to be attached to the tracer. Attachment and sub‐
22 sequent commands are per thread: in a multithreaded process, every
23 thread can be individually attached to a (potentially different)
24 tracer, or left not attached and thus not debugged. Therefore,
25 "tracee" always means "(one) thread", never "a (possibly multithreaded)
26 process". Ptrace commands are always sent to a specific tracee using a
27 call of the form
28 ptrace(PTRACE_foo, pid, ...)
30 where pid is the thread ID of the corresponding Linux thread.
32 (Note that in this page, a "multithreaded process" means a thread group
34 consisting of threads created using the clone(2) CLONE_THREAD flag.)
35 A process can initiate a trace by calling fork(2) and having the
37 resulting child do a PTRACE_TRACEME, followed (typically) by an
38 execve(2). Alternatively, one process may commence tracing another
39 process using PTRACE_ATTACH or PTRACE_SEIZE.
40 While being traced, the tracee will stop each time a signal is deliv‐
42 ered, even if the signal is being ignored. (An exception is SIGKILL,
43 which has its usual effect.) The tracer will be notified at its next
44 call to waitpid(2) (or one of the related "wait" system calls); that
45 call will return a status value containing information that indicates
46 the cause of the stop in the tracee. While the tracee is stopped, the
47 tracer can use various ptrace requests to inspect and modify the
48 tracee. The tracer then causes the tracee to continue, optionally
49 ignoring the delivered signal (or even delivering a different signal
50 instead).
51 If the PTRACE_O_TRACEEXEC option is not in effect, all successful calls
53 to execve(2) by the traced process will cause it to be sent a SIGTRAP
54 signal, giving the parent a chance to gain control before the new pro‐
55 gram begins execution.
56 When the tracer is finished tracing, it can cause the tracee to con‐
58 tinue executing in a normal, untraced mode via PTRACE_DETACH.
59 The value of request determines the action to be performed:
61 PTRACE_TRACEME
63 Indicate that this process is to be traced by its parent. A
64 process probably shouldn't make this request if its parent isn't
65 expecting to trace it. (pid, addr, and data are ignored.)
66 The PTRACE_TRACEME request is used only by the tracee; the remaining
68 requests are used only by the tracer. In the following requests, pid
69 specifies the thread ID of the tracee to be acted on. For requests
70 other than PTRACE_ATTACH, PTRACE_SEIZE, PTRACE_INTERRUPT and
71 PTRACE_KILL, the tracee must be stopped.
72 PTRACE_PEEKTEXT, PTRACE_PEEKDATA
74 Read a word at the address addr in the tracee's memory, return‐
75 ing the word as the result of the ptrace() call. Linux does not
76 have separate text and data address spaces, so these two
77 requests are currently equivalent. (data is ignored.)
78 PTRACE_PEEKUSER
80 Read a word at offset addr in the tracee's USER area, which
81 holds the registers and other information about the process (see
82 <sys/user.h>). The word is returned as the result of the
83 ptrace() call. Typically, the offset must be word-aligned,
84 though this might vary by architecture. See NOTES. (data is
85 ignored.)
86 PTRACE_POKETEXT, PTRACE_POKEDATA
88 Copy the word data to the address addr in the tracee's memory.
89 As for PTRACE_PEEKTEXT and PTRACE_PEEKDATA, these two requests
90 are currently equivalent.
91 PTRACE_POKEUSER
93 Copy the word data to offset addr in the tracee's USER area. As
94 for PTRACE_PEEKUSER, the offset must typically be word-aligned.
95 In order to maintain the integrity of the kernel, some modifica‐
96 tions to the USER area are disallowed.
97 PTRACE_GETREGS, PTRACE_GETFPREGS
99 Copy the tracee's general-purpose or floating-point registers,
100 respectively, to the address data in the tracer. See
101 <sys/user.h> for information on the format of this data. (addr
102 is ignored.) Note that SPARC systems have the meaning of data
103 and addr reversed; that is, data is ignored and the registers
104 are copied to the address addr. PTRACE_GETREGS and PTRACE_GETF‐
105 PREGS are not present on all architectures.
106 PTRACE_GETREGSET (since Linux 2.6.34)
108 Read the tracee's registers. addr specifies, in an architec‐
109 ture-dependent way, the type of registers to be read. NT_PRSTA‐
110 TUS (with numerical value 1) usually results in reading of gen‐
111 eral-purpose registers. If the CPU has, for example, floating-
112 point and/or vector registers, they can be retrieved by setting
113 addr to the corresponding NT_foo constant. data points to a
114 struct iovec, which describes the destination buffer's location
115 and length. On return, the kernel modifies iov.len to indicate
116 the actual number of bytes returned.
117 PTRACE_SETREGS, PTRACE_SETFPREGS
119 Modify the tracee's general-purpose or floating-point registers,
120 respectively, from the address data in the tracer. As for
121 PTRACE_POKEUSER, some general-purpose register modifications may
122 be disallowed. (addr is ignored.) Note that SPARC systems have
123 the meaning of data and addr reversed; that is, data is ignored
124 and the registers are copied from the address addr.
125 PTRACE_SETREGS and PTRACE_SETFPREGS are not present on all
126 architectures.
127 PTRACE_SETREGSET (since Linux 2.6.34)
129 Modify the tracee's registers. The meaning of addr and data is
130 analogous to PTRACE_GETREGSET.
131 PTRACE_GETSIGINFO (since Linux 2.3.99-pre6)
133 Retrieve information about the signal that caused the stop.
134 Copy a siginfo_t structure (see sigaction(2)) from the tracee to
135 the address data in the tracer. (addr is ignored.)
136 PTRACE_SETSIGINFO (since Linux 2.3.99-pre6)
138 Set signal information: copy a siginfo_t structure from the
139 address data in the tracer to the tracee. This will affect only
140 signals that would normally be delivered to the tracee and were
141 caught by the tracer. It may be difficult to tell these normal
142 signals from synthetic signals generated by ptrace() itself.
143 (addr is ignored.)
144 PTRACE_SETOPTIONS (since Linux 2.4.6; see BUGS for caveats)
146 Set ptrace options from data. (addr is ignored.) data is
147 interpreted as a bit mask of options, which are specified by the
148 following flags:
149 PTRACE_O_EXITKILL (since Linux 3.8)
151 If a tracer sets this flag, a SIGKILL signal will be sent
152 to every tracee if the tracer exits. This option is use‐
153 ful for ptrace jailers that want to ensure that tracees
154 can never escape the tracer's control.
155 PTRACE_O_TRACECLONE (since Linux 2.5.46)
157 Stop the tracee at the next clone(2) and automatically
158 start tracing the newly cloned process, which will start
159 with a SIGSTOP, or PTRACE_EVENT_STOP if PTRACE_SEIZE was
160 used. A waitpid(2) by the tracer will return a status
161 value such that
162 status>>8 == (SIGTRAP | (PTRACE_EVENT_CLONE<<8))
164 The PID of the new process can be retrieved with
166 PTRACE_GETEVENTMSG.
167 This option may not catch clone(2) calls in all cases.
169 If the tracee calls clone(2) with the CLONE_VFORK flag,
170 PTRACE_EVENT_VFORK will be delivered instead if
171 PTRACE_O_TRACEVFORK is set; otherwise if the tracee calls
172 clone(2) with the exit signal set to SIGCHLD,
173 PTRACE_EVENT_FORK will be delivered if PTRACE_O_TRACEFORK
174 is set.
175 PTRACE_O_TRACEEXEC (since Linux 2.5.46)
177 Stop the tracee at the next execve(2). A waitpid(2) by
178 the tracer will return a status value such that
179 status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8))
181 If the execing thread is not a thread group leader, the
183 thread ID is reset to thread group leader's ID before
184 this stop. Since Linux 3.0, the former thread ID can be
185 retrieved with PTRACE_GETEVENTMSG.
186 PTRACE_O_TRACEEXIT (since Linux 2.5.60)
188 Stop the tracee at exit. A waitpid(2) by the tracer will
189 return a status value such that
190 status>>8 == (SIGTRAP | (PTRACE_EVENT_EXIT<<8))
192 The tracee's exit status can be retrieved with
194 PTRACE_GETEVENTMSG.
195 The tracee is stopped early during process exit, when
197 registers are still available, allowing the tracer to see
198 where the exit occurred, whereas the normal exit notifi‐
199 cation is done after the process is finished exiting.
200 Even though context is available, the tracer cannot pre‐
201 vent the exit from happening at this point.
202 PTRACE_O_TRACEFORK (since Linux 2.5.46)
204 Stop the tracee at the next fork(2) and automatically
205 start tracing the newly forked process, which will start
206 with a SIGSTOP, or PTRACE_EVENT_STOP if PTRACE_SEIZE was
207 used. A waitpid(2) by the tracer will return a status
208 value such that
209 status>>8 == (SIGTRAP | (PTRACE_EVENT_FORK<<8))
211 The PID of the new process can be retrieved with
213 PTRACE_GETEVENTMSG.
214 PTRACE_O_TRACESYSGOOD (since Linux 2.4.6)
216 When delivering system call traps, set bit 7 in the sig‐
217 nal number (i.e., deliver SIGTRAP|0x80). This makes it
218 easy for the tracer to distinguish normal traps from
219 those caused by a system call. (PTRACE_O_TRACESYSGOOD
220 may not work on all architectures.)
221 PTRACE_O_TRACEVFORK (since Linux 2.5.46)
223 Stop the tracee at the next vfork(2) and automatically
224 start tracing the newly vforked process, which will start
225 with a SIGSTOP, or PTRACE_EVENT_STOP if PTRACE_SEIZE was
226 used. A waitpid(2) by the tracer will return a status
227 value such that
228 status>>8 == (SIGTRAP | (PTRACE_EVENT_VFORK<<8))
230 The PID of the new process can be retrieved with
232 PTRACE_GETEVENTMSG.
233 PTRACE_O_TRACEVFORKDONE (since Linux 2.5.60)
235 Stop the tracee at the completion of the next vfork(2).
236 A waitpid(2) by the tracer will return a status value
237 such that
238 status>>8 == (SIGTRAP | (PTRACE_EVENT_VFORK_DONE<<8))
240 The PID of the new process can (since Linux 2.6.18) be
242 retrieved with PTRACE_GETEVENTMSG.
243 PTRACE_GETEVENTMSG (since Linux 2.5.46)
245 Retrieve a message (as an unsigned long) about the ptrace event
246 that just happened, placing it at the address data in the
247 tracer. For PTRACE_EVENT_EXIT, this is the tracee's exit sta‐
248 tus. For PTRACE_EVENT_FORK, PTRACE_EVENT_VFORK,
249 PTRACE_EVENT_VFORK_DONE, and PTRACE_EVENT_CLONE, this is the PID
250 of the new process. (addr is ignored.)
251 PTRACE_CONT
253 Restart the stopped tracee process. If data is nonzero, it is
254 interpreted as the number of a signal to be delivered to the
255 tracee; otherwise, no signal is delivered. Thus, for example,
256 the tracer can control whether a signal sent to the tracee is
257 delivered or not. (addr is ignored.)
258 PTRACE_SYSCALL, PTRACE_SINGLESTEP
260 Restart the stopped tracee as for PTRACE_CONT, but arrange for
261 the tracee to be stopped at the next entry to or exit from a
262 system call, or after execution of a single instruction, respec‐
263 tively. (The tracee will also, as usual, be stopped upon
264 receipt of a signal.) From the tracer's perspective, the tracee
265 will appear to have been stopped by receipt of a SIGTRAP. So,
266 for PTRACE_SYSCALL, for example, the idea is to inspect the
267 arguments to the system call at the first stop, then do another
268 PTRACE_SYSCALL and inspect the return value of the system call
269 at the second stop. The data argument is treated as for
270 PTRACE_CONT. (addr is ignored.)
271 PTRACE_SYSEMU, PTRACE_SYSEMU_SINGLESTEP (since Linux 2.6.14)
273 For PTRACE_SYSEMU, continue and stop on entry to the next system
274 call, which will not be executed. For PTRACE_SYSEMU_SINGLESTEP,
275 do the same but also singlestep if not a system call. This call
276 is used by programs like User Mode Linux that want to emulate
277 all the tracee's system calls. The data argument is treated as
278 for PTRACE_CONT. The addr argument is ignored. These requests
279 are currently supported only on x86.
280 PTRACE_LISTEN (since Linux 3.4)
282 Restart the stopped tracee, but prevent it from executing. The
283 resulting state of the tracee is similar to a process which has
284 been stopped by a SIGSTOP (or other stopping signal). See the
285 "group-stop" subsection for additional information. PTRACE_LIS‐
286 TEN works only on tracees attached by PTRACE_SEIZE.
287 PTRACE_KILL
289 Send the tracee a SIGKILL to terminate it. (addr and data are
290 ignored.)
291 This operation is deprecated; do not use it! Instead, send a
293 SIGKILL directly using kill(2) or tgkill(2). The problem with
294 PTRACE_KILL is that it requires the tracee to be in signal-
295 delivery-stop, otherwise it may not work (i.e., may complete
296 successfully but won't kill the tracee). By contrast, sending a
297 SIGKILL directly has no such limitation.
298 PTRACE_INTERRUPT (since Linux 3.4)
300 Stop a tracee. If the tracee is running or sleeping in kernel
301 space and PTRACE_SYSCALL is in effect, the system call is inter‐
302 rupted and syscall-exit-stop is reported. (The interrupted sys‐
303 tem call is restarted when the tracee is restarted.) If the
304 tracee was already stopped by a signal and PTRACE_LISTEN was
305 sent to it, the tracee stops with PTRACE_EVENT_STOP and WSTOP‐
306 SIG(status) returns the stop signal. If any other ptrace-stop
307 is generated at the same time (for example, if a signal is sent
308 to the tracee), this ptrace-stop happens. If none of the above
309 applies (for example, if the tracee is running in userspace), it
310 stops with PTRACE_EVENT_STOP with WSTOPSIG(status) == SIGTRAP.
311 PTRACE_INTERRUPT only works on tracees attached by PTRACE_SEIZE.
312 PTRACE_ATTACH
314 Attach to the process specified in pid, making it a tracee of
315 the calling process. The tracee is sent a SIGSTOP, but will not
316 necessarily have stopped by the completion of this call; use
317 waitpid(2) to wait for the tracee to stop. See the "Attaching
318 and detaching" subsection for additional information. (addr and
319 data are ignored.)
320 PTRACE_SEIZE (since Linux 3.4)
322 Attach to the process specified in pid, making it a tracee of
323 the calling process. Unlike PTRACE_ATTACH, PTRACE_SEIZE does
324 not stop the process. Only a PTRACE_SEIZEd process can accept
325 PTRACE_INTERRUPT and PTRACE_LISTEN commands. addr must be zero.
326 data contains a bit mask of ptrace options to activate immedi‐
327 ately.
328 PTRACE_DETACH
330 Restart the stopped tracee as for PTRACE_CONT, but first detach
331 from it. Under Linux, a tracee can be detached in this way
332 regardless of which method was used to initiate tracing. (addr
333 is ignored.)
334 Death under ptrace
336 When a (possibly multithreaded) process receives a killing signal (one
337 whose disposition is set to SIG_DFL and whose default action is to kill
338 the process), all threads exit. Tracees report their death to their
339 tracer(s). Notification of this event is delivered via waitpid(2).
340 Note that the killing signal will first cause signal-delivery-stop (on
342 one tracee only), and only after it is injected by the tracer (or after
343 it was dispatched to a thread which isn't traced), will death from the
344 signal happen on all tracees within a multithreaded process. (The term
345 "signal-delivery-stop" is explained below.)
346 SIGKILL does not generate signal-delivery-stop and therefore the tracer
348 can't suppress it. SIGKILL kills even within system calls (syscall-
349 exit-stop is not generated prior to death by SIGKILL). The net effect
350 is that SIGKILL always kills the process (all its threads), even if
351 some threads of the process are ptraced.
352 When the tracee calls _exit(2), it reports its death to its tracer.
354 Other threads are not affected.
355 When any thread executes exit_group(2), every tracee in its thread
357 group reports its death to its tracer.
358 If the PTRACE_O_TRACEEXIT option is on, PTRACE_EVENT_EXIT will happen
360 before actual death. This applies to exits via exit(2), exit_group(2),
361 and signal deaths (except SIGKILL), and when threads are torn down on
362 execve(2) in a multithreaded process.
363 The tracer cannot assume that the ptrace-stopped tracee exists. There
365 are many scenarios when the tracee may die while stopped (such as
366 SIGKILL). Therefore, the tracer must be prepared to handle an ESRCH
367 error on any ptrace operation. Unfortunately, the same error is
368 returned if the tracee exists but is not ptrace-stopped (for commands
369 which require a stopped tracee), or if it is not traced by the process
370 which issued the ptrace call. The tracer needs to keep track of the
371 stopped/running state of the tracee, and interpret ESRCH as "tracee
372 died unexpectedly" only if it knows that the tracee has been observed
373 to enter ptrace-stop. Note that there is no guarantee that wait‐
374 pid(WNOHANG) will reliably report the tracee's death status if a ptrace
375 operation returned ESRCH. waitpid(WNOHANG) may return 0 instead. In
376 other words, the tracee may be "not yet fully dead", but already refus‐
377 ing ptrace requests.
378 The tracer can't assume that the tracee always ends its life by report‐
380 ing WIFEXITED(status) or WIFSIGNALED(status); there are cases where
381 this does not occur. For example, if a thread other than thread group
382 leader does an execve(2), it disappears; its PID will never be seen
383 again, and any subsequent ptrace stops will be reported under the
384 thread group leader's PID.
385 Stopped states
387 A tracee can be in two states: running or stopped. For the purposes of
388 ptrace, a tracee which is blocked in a system call (such as read(2),
389 pause(2), etc.) is nevertheless considered to be running, even if the
390 tracee is blocked for a long time. The state of the tracee after
391 PTRACE_LISTEN is somewhat of a gray area: it is not in any ptrace-stop
392 (ptrace commands won't work on it, and it will deliver waitpid(2) noti‐
393 fications), but it also may be considered "stopped" because it is not
394 executing instructions (is not scheduled), and if it was in group-stop
395 before PTRACE_LISTEN, it will not respond to signals until SIGCONT is
396 received.
397 There are many kinds of states when the tracee is stopped, and in
399 ptrace discussions they are often conflated. Therefore, it is impor‐
400 tant to use precise terms.
401 In this manual page, any stopped state in which the tracee is ready to
403 accept ptrace commands from the tracer is called ptrace-stop. Ptrace-
404 stops can be further subdivided into signal-delivery-stop, group-stop,
405 syscall-stop, and so on. These stopped states are described in detail
406 below.
407 When the running tracee enters ptrace-stop, it notifies its tracer
409 using waitpid(2) (or one of the other "wait" system calls). Most of
410 this manual page assumes that the tracer waits with:
411 pid = waitpid(pid_or_minus_1, &status, __WALL);
413 Ptrace-stopped tracees are reported as returns with pid greater than 0
415 and WIFSTOPPED(status) true.
416 The __WALL flag does not include the WSTOPPED and WEXITED flags, but
418 implies their functionality.
419 Setting the WCONTINUED flag when calling waitpid(2) is not recommended:
421 the "continued" state is per-process and consuming it can confuse the
422 real parent of the tracee.
423 Use of the WNOHANG flag may cause waitpid(2) to return 0 ("no wait
425 results available yet") even if the tracer knows there should be a
426 notification. Example:
427 errno = 0;
429 ptrace(PTRACE_CONT, pid, 0L, 0L);
430 if (errno == ESRCH) {
431 /* tracee is dead */
432 r = waitpid(tracee, &status, __WALL | WNOHANG);
433 /* r can still be 0 here! */
434 }
435 The following kinds of ptrace-stops exist: signal-delivery-stops,
437 group-stops, PTRACE_EVENT stops, syscall-stops. They all are reported
438 by waitpid(2) with WIFSTOPPED(status) true. They may be differentiated
439 by examining the value status>>8, and if there is ambiguity in that
440 value, by querying PTRACE_GETSIGINFO. (Note: the WSTOPSIG(status)
441 macro can't be used to perform this examination, because it returns the
442 value (status>>8) & 0xff.)
443 Signal-delivery-stop
445 When a (possibly multithreaded) process receives any signal except
446 SIGKILL, the kernel selects an arbitrary thread which handles the sig‐
447 nal. (If the signal is generated with tgkill(2), the target thread can
448 be explicitly selected by the caller.) If the selected thread is
449 traced, it enters signal-delivery-stop. At this point, the signal is
450 not yet delivered to the process, and can be suppressed by the tracer.
451 If the tracer doesn't suppress the signal, it passes the signal to the
452 tracee in the next ptrace restart request. This second step of signal
453 delivery is called signal injection in this manual page. Note that if
454 the signal is blocked, signal-delivery-stop doesn't happen until the
455 signal is unblocked, with the usual exception that SIGSTOP can't be
456 blocked.
457 Signal-delivery-stop is observed by the tracer as waitpid(2) returning
459 with WIFSTOPPED(status) true, with the signal returned by WSTOPSIG(sta‐
460 tus). If the signal is SIGTRAP, this may be a different kind of
461 ptrace-stop; see the "Syscall-stops" and "execve" sections below for
462 details. If WSTOPSIG(status) returns a stopping signal, this may be a
463 group-stop; see below.
464 Signal injection and suppression
466 After signal-delivery-stop is observed by the tracer, the tracer should
467 restart the tracee with the call
468 ptrace(PTRACE_restart, pid, 0, sig)
470 where PTRACE_restart is one of the restarting ptrace requests. If sig
472 is 0, then a signal is not delivered. Otherwise, the signal sig is
473 delivered. This operation is called signal injection in this manual
474 page, to distinguish it from signal-delivery-stop.
475 The sig value may be different from the WSTOPSIG(status) value: the
477 tracer can cause a different signal to be injected.
478 Note that a suppressed signal still causes system calls to return pre‐
480 maturely. In this case system calls will be restarted: the tracer will
481 observe the tracee to reexecute the interrupted system call (or
482 restart_syscall(2) system call for a few syscalls which use a different
483 mechanism for restarting) if the tracer uses PTRACE_SYSCALL. Even sys‐
484 tem calls (such as poll(2)) which are not restartable after signal are
485 restarted after signal is suppressed; however, kernel bugs exist which
486 cause some syscalls to fail with EINTR even though no observable signal
487 is injected to the tracee.
488 Restarting ptrace commands issued in ptrace-stops other than signal-
490 delivery-stop are not guaranteed to inject a signal, even if sig is
491 nonzero. No error is reported; a nonzero sig may simply be ignored.
492 Ptrace users should not try to "create a new signal" this way: use
493 tgkill(2) instead.
494 The fact that signal injection requests may be ignored when restarting
496 the tracee after ptrace stops that are not signal-delivery-stops is a
497 cause of confusion among ptrace users. One typical scenario is that
498 the tracer observes group-stop, mistakes it for signal-delivery-stop,
499 restarts the tracee with
500 ptrace(PTRACE_restart, pid, 0, stopsig)
502 with the intention of injecting stopsig, but stopsig gets ignored and
504 the tracee continues to run.
505 The SIGCONT signal has a side effect of waking up (all threads of) a
507 group-stopped process. This side effect happens before signal-deliv‐
508 ery-stop. The tracer can't suppress this side effect (it can only sup‐
509 press signal injection, which only causes the SIGCONT handler to not be
510 executed in the tracee, if such a handler is installed). In fact, wak‐
511 ing up from group-stop may be followed by signal-delivery-stop for sig‐
512 nal(s) other than SIGCONT, if they were pending when SIGCONT was deliv‐
513 ered. In other words, SIGCONT may be not the first signal observed by
514 the tracee after it was sent.
515 Stopping signals cause (all threads of) a process to enter group-stop.
517 This side effect happens after signal injection, and therefore can be
518 suppressed by the tracer.
519 In Linux 2.4 and earlier, the SIGSTOP signal can't be injected.
521 PTRACE_GETSIGINFO can be used to retrieve a siginfo_t structure which
523 corresponds to the delivered signal. PTRACE_SETSIGINFO may be used to
524 modify it. If PTRACE_SETSIGINFO has been used to alter siginfo_t, the
525 si_signo field and the sig parameter in the restarting command must
526 match, otherwise the result is undefined.
527 Group-stop
529 When a (possibly multithreaded) process receives a stopping signal, all
530 threads stop. If some threads are traced, they enter a group-stop.
531 Note that the stopping signal will first cause signal-delivery-stop (on
532 one tracee only), and only after it is injected by the tracer (or after
533 it was dispatched to a thread which isn't traced), will group-stop be
534 initiated on all tracees within the multithreaded process. As usual,
535 every tracee reports its group-stop separately to the corresponding
536 tracer.
537 Group-stop is observed by the tracer as waitpid(2) returning with WIF‐
539 STOPPED(status) true, with the stopping signal available via WSTOP‐
540 SIG(status). The same result is returned by some other classes of
541 ptrace-stops, therefore the recommended practice is to perform the call
542 ptrace(PTRACE_GETSIGINFO, pid, 0, &siginfo)
544 The call can be avoided if the signal is not SIGSTOP, SIGTSTP, SIGTTIN,
546 or SIGTTOU; only these four signals are stopping signals. If the
547 tracer sees something else, it can't be a group-stop. Otherwise, the
548 tracer needs to call PTRACE_GETSIGINFO. If PTRACE_GETSIGINFO fails
549 with EINVAL, then it is definitely a group-stop. (Other failure codes
550 are possible, such as ESRCH ("no such process") if a SIGKILL killed the
551 tracee.)
552 If tracee was attached using PTRACE_SEIZE, group-stop is indicated by
554 PTRACE_EVENT_STOP: status>>16 == PTRACE_EVENT_STOP. This allows detec‐
555 tion of group-stops without requiring an extra PTRACE_GETSIGINFO call.
556 As of Linux 2.6.38, after the tracer sees the tracee ptrace-stop and
558 until it restarts or kills it, the tracee will not run, and will not
559 send notifications (except SIGKILL death) to the tracer, even if the
560 tracer enters into another waitpid(2) call.
561 The kernel behavior described in the previous paragraph causes a prob‐
563 lem with transparent handling of stopping signals. If the tracer
564 restarts the tracee after group-stop, the stopping signal is effec‐
565 tively ignored—the tracee doesn't remain stopped, it runs. If the
566 tracer doesn't restart the tracee before entering into the next wait‐
567 pid(2), future SIGCONT signals will not be reported to the tracer; this
568 would cause the SIGCONT signals to have no effect on the tracee.
569 Since Linux 3.4, there is a method to overcome this problem: instead of
571 PTRACE_CONT, a PTRACE_LISTEN command can be used to restart a tracee in
572 a way where it does not execute, but waits for a new event which it can
573 report via waitpid(2) (such as when it is restarted by a SIGCONT).
574 PTRACE_EVENT stops
576 If the tracer sets PTRACE_O_TRACE_* options, the tracee will enter
577 ptrace-stops called PTRACE_EVENT stops.
578 PTRACE_EVENT stops are observed by the tracer as waitpid(2) returning
580 with WIFSTOPPED(status), and WSTOPSIG(status) returns SIGTRAP. An
581 additional bit is set in the higher byte of the status word: the value
582 status>>8 will be
583 (SIGTRAP | PTRACE_EVENT_foo << 8).
585 The following events exist:
587 PTRACE_EVENT_VFORK
589 Stop before return from vfork(2) or clone(2) with the
590 CLONE_VFORK flag. When the tracee is continued after this stop,
591 it will wait for child to exit/exec before continuing its execu‐
592 tion (in other words, the usual behavior on vfork(2)).
593 PTRACE_EVENT_FORK
595 Stop before return from fork(2) or clone(2) with the exit signal
596 set to SIGCHLD.
597 PTRACE_EVENT_CLONE
599 Stop before return from clone(2).
600 PTRACE_EVENT_VFORK_DONE
602 Stop before return from vfork(2) or clone(2) with the
603 CLONE_VFORK flag, but after the child unblocked this tracee by
604 exiting or execing.
605 For all four stops described above, the stop occurs in the parent
607 (i.e., the tracee), not in the newly created thread.
608 PTRACE_GETEVENTMSG can be used to retrieve the new thread's ID.
609 PTRACE_EVENT_EXEC
611 Stop before return from execve(2). Since Linux 3.0,
612 PTRACE_GETEVENTMSG returns the former thread ID.
613 PTRACE_EVENT_EXIT
615 Stop before exit (including death from exit_group(2)), signal
616 death, or exit caused by execve(2) in a multithreaded process.
617 PTRACE_GETEVENTMSG returns the exit status. Registers can be
618 examined (unlike when "real" exit happens). The tracee is still
619 alive; it needs to be PTRACE_CONTed or PTRACE_DETACHed to finish
620 exiting.
621 PTRACE_EVENT_STOP
623 Stop induced by PTRACE_INTERRUPT command, or group-stop, or ini‐
624 tial ptrace-stop when a new child is attached (only if attached
625 using PTRACE_SEIZE). or PTRACE_EVENT_STOP if PTRACE_SEIZE was
626 used.
627 PTRACE_GETSIGINFO on PTRACE_EVENT stops returns SIGTRAP in si_signo,
629 with si_code set to (event<<8) | SIGTRAP.
630 Syscall-stops
632 If the tracee was restarted by PTRACE_SYSCALL, the tracee enters
633 syscall-enter-stop just prior to entering any system call. If the
634 tracer restarts the tracee with PTRACE_SYSCALL, the tracee enters
635 syscall-exit-stop when the system call is finished, or if it is inter‐
636 rupted by a signal. (That is, signal-delivery-stop never happens
637 between syscall-enter-stop and syscall-exit-stop; it happens after
638 syscall-exit-stop.)
639 Other possibilities are that the tracee may stop in a PTRACE_EVENT
641 stop, exit (if it entered _exit(2) or exit_group(2)), be killed by
642 SIGKILL, or die silently (if it is a thread group leader, the execve(2)
643 happened in another thread, and that thread is not traced by the same
644 tracer; this situation is discussed later).
645 Syscall-enter-stop and syscall-exit-stop are observed by the tracer as
647 waitpid(2) returning with WIFSTOPPED(status) true, and WSTOPSIG(status)
648 giving SIGTRAP. If the PTRACE_O_TRACESYSGOOD option was set by the
649 tracer, then WSTOPSIG(status) will give the value (SIGTRAP | 0x80).
650 Syscall-stops can be distinguished from signal-delivery-stop with SIG‐
652 TRAP by querying PTRACE_GETSIGINFO for the following cases:
653 si_code <= 0
655 SIGTRAP was delivered as a result of a user-space action, for
656 example, a system call (tgkill(2), kill(2), sigqueue(3), etc.),
657 expiration of a POSIX timer, change of state on a POSIX message
658 queue, or completion of an asynchronous I/O request.
659 si_code == SI_KERNEL (0x80)
661 SIGTRAP was sent by the kernel.
662 si_code == SIGTRAP or si_code == (SIGTRAP|0x80)
664 This is a syscall-stop.
665 However, syscall-stops happen very often (twice per system call), and
667 performing PTRACE_GETSIGINFO for every syscall-stop may be somewhat
668 expensive.
669 Some architectures allow the cases to be distinguished by examining
671 registers. For example, on x86, rax == -ENOSYS in syscall-enter-stop.
672 Since SIGTRAP (like any other signal) always happens after syscall-
673 exit-stop, and at this point rax almost never contains -ENOSYS, the
674 SIGTRAP looks like "syscall-stop which is not syscall-enter-stop"; in
675 other words, it looks like a "stray syscall-exit-stop" and can be
676 detected this way. But such detection is fragile and is best avoided.
677 Using the PTRACE_O_TRACESYSGOOD option is the recommended method to
679 distinguish syscall-stops from other kinds of ptrace-stops, since it is
680 reliable and does not incur a performance penalty.
681 Syscall-enter-stop and syscall-exit-stop are indistinguishable from
683 each other by the tracer. The tracer needs to keep track of the
684 sequence of ptrace-stops in order to not misinterpret syscall-enter-
685 stop as syscall-exit-stop or vice versa. The rule is that syscall-
686 enter-stop is always followed by syscall-exit-stop, PTRACE_EVENT stop
687 or the tracee's death; no other kinds of ptrace-stop can occur in
688 between.
689 If after syscall-enter-stop, the tracer uses a restarting command other
691 than PTRACE_SYSCALL, syscall-exit-stop is not generated.
692 PTRACE_GETSIGINFO on syscall-stops returns SIGTRAP in si_signo, with
694 si_code set to SIGTRAP or (SIGTRAP|0x80).
695 PTRACE_SINGLESTEP, PTRACE_SYSEMU, PTRACE_SYSEMU_SINGLESTEP stops
697 [Details of these kinds of stops are yet to be documented.]
698 Informational and restarting ptrace commands
700 Most ptrace commands (all except PTRACE_ATTACH, PTRACE_SEIZE,
701 PTRACE_TRACEME, PTRACE_INTERRUPT, and PTRACE_KILL) require the tracee
702 to be in a ptrace-stop, otherwise they fail with ESRCH.
703 When the tracee is in ptrace-stop, the tracer can read and write data
705 to the tracee using informational commands. These commands leave the
706 tracee in ptrace-stopped state:
707 ptrace(PTRACE_PEEKTEXT/PEEKDATA/PEEKUSER, pid, addr, 0);
709 ptrace(PTRACE_POKETEXT/POKEDATA/POKEUSER, pid, addr, long_val);
710 ptrace(PTRACE_GETREGS/GETFPREGS, pid, 0, &struct);
711 ptrace(PTRACE_SETREGS/SETFPREGS, pid, 0, &struct);
712 ptrace(PTRACE_GETREGSET, pid, NT_foo, &iov);
713 ptrace(PTRACE_SETREGSET, pid, NT_foo, &iov);
714 ptrace(PTRACE_GETSIGINFO, pid, 0, &siginfo);
715 ptrace(PTRACE_SETSIGINFO, pid, 0, &siginfo);
716 ptrace(PTRACE_GETEVENTMSG, pid, 0, &long_var);
717 ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_flags);
718 Note that some errors are not reported. For example, setting signal
720 information (siginfo) may have no effect in some ptrace-stops, yet the
721 call may succeed (return 0 and not set errno); querying
722 PTRACE_GETEVENTMSG may succeed and return some random value if current
723 ptrace-stop is not documented as returning a meaningful event message.
724 The call
726 ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_flags);
728 affects one tracee. The tracee's current flags are replaced. Flags
730 are inherited by new tracees created and "auto-attached" via active
731 PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
732 options.
733 Another group of commands makes the ptrace-stopped tracee run. They
735 have the form:
736 ptrace(cmd, pid, 0, sig);
738 where cmd is PTRACE_CONT, PTRACE_LISTEN, PTRACE_DETACH, PTRACE_SYSCALL,
740 PTRACE_SINGLESTEP, PTRACE_SYSEMU, or PTRACE_SYSEMU_SINGLESTEP. If the
741 tracee is in signal-delivery-stop, sig is the signal to be injected (if
742 it is nonzero). Otherwise, sig may be ignored. (When restarting a
743 tracee from a ptrace-stop other than signal-delivery-stop, recommended
744 practice is to always pass 0 in sig.)
745 Attaching and detaching
747 A thread can be attached to the tracer using the call
748 ptrace(PTRACE_ATTACH, pid, 0, 0);
750 or
752 ptrace(PTRACE_SEIZE, pid, 0, PTRACE_O_flags);
754 PTRACE_ATTACH sends SIGSTOP to this thread. If the tracer wants this
756 SIGSTOP to have no effect, it needs to suppress it. Note that if other
757 signals are concurrently sent to this thread during attach, the tracer
758 may see the tracee enter signal-delivery-stop with other signal(s)
759 first! The usual practice is to reinject these signals until SIGSTOP
760 is seen, then suppress SIGSTOP injection. The design bug here is that
761 a ptrace attach and a concurrently delivered SIGSTOP may race and the
762 concurrent SIGSTOP may be lost.
763 Since attaching sends SIGSTOP and the tracer usually suppresses it,
765 this may cause a stray EINTR return from the currently executing system
766 call in the tracee, as described in the "Signal injection and suppres‐
767 sion" section.
768 Since Linux 3.4, PTRACE_SEIZE can be used instead of PTRACE_ATTACH.
770 PTRACE_SEIZE does not stop the attached process. If you need to stop
771 it after attach (or at any other time) without sending it any signals,
772 use PTRACE_INTERRUPT command.
773 The request
775 ptrace(PTRACE_TRACEME, 0, 0, 0);
777 turns the calling thread into a tracee. The thread continues to run
779 (doesn't enter ptrace-stop). A common practice is to follow the
780 PTRACE_TRACEME with
781 raise(SIGSTOP);
783 and allow the parent (which is our tracer now) to observe our signal-
785 delivery-stop.
786 If the PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
788 options are in effect, then children created by, respectively, vfork(2)
789 or clone(2) with the CLONE_VFORK flag, fork(2) or clone(2) with the
790 exit signal set to SIGCHLD, and other kinds of clone(2), are automati‐
791 cally attached to the same tracer which traced their parent. SIGSTOP
792 is delivered to the children, causing them to enter signal-delivery-
793 stop after they exit the system call which created them.
794 Detaching of the tracee is performed by:
796 ptrace(PTRACE_DETACH, pid, 0, sig);
798 PTRACE_DETACH is a restarting operation; therefore it requires the
800 tracee to be in ptrace-stop. If the tracee is in signal-delivery-stop,
801 a signal can be injected. Otherwise, the sig parameter may be silently
802 ignored.
803 If the tracee is running when the tracer wants to detach it, the usual
805 solution is to send SIGSTOP (using tgkill(2), to make sure it goes to
806 the correct thread), wait for the tracee to stop in signal-delivery-
807 stop for SIGSTOP and then detach it (suppressing SIGSTOP injection). A
808 design bug is that this can race with concurrent SIGSTOPs. Another
809 complication is that the tracee may enter other ptrace-stops and needs
810 to be restarted and waited for again, until SIGSTOP is seen. Yet
811 another complication is to be sure that the tracee is not already
812 ptrace-stopped, because no signal delivery happens while it is—not even
813 SIGSTOP.
814 If the tracer dies, all tracees are automatically detached and
816 restarted, unless they were in group-stop. Handling of restart from
817 group-stop is currently buggy, but the "as planned" behavior is to
818 leave tracee stopped and waiting for SIGCONT. If the tracee is
819 restarted from signal-delivery-stop, the pending signal is injected.
820 execve(2) under ptrace
822 When one thread in a multithreaded process calls execve(2), the kernel
823 destroys all other threads in the process, and resets the thread ID of
824 the execing thread to the thread group ID (process ID). (Or, to put
825 things another way, when a multithreaded process does an execve(2), at
826 completion of the call, it appears as though the execve(2) occurred in
827 the thread group leader, regardless of which thread did the execve(2).)
828 This resetting of the thread ID looks very confusing to tracers:
829 * All other threads stop in PTRACE_EVENT_EXIT stop, if the
831 PTRACE_O_TRACEEXIT option was turned on. Then all other threads
832 except the thread group leader report death as if they exited via
833 _exit(2) with exit code 0.
834 * The execing tracee changes its thread ID while it is in the
836 execve(2). (Remember, under ptrace, the "pid" returned from wait‐
837 pid(2), or fed into ptrace calls, is the tracee's thread ID.) That
838 is, the tracee's thread ID is reset to be the same as its process
839 ID, which is the same as the thread group leader's thread ID.
840 * Then a PTRACE_EVENT_EXEC stop happens, if the PTRACE_O_TRACEEXEC
842 option was turned on.
843 * If the thread group leader has reported its PTRACE_EVENT_EXIT stop
845 by this time, it appears to the tracer that the dead thread leader
846 "reappears from nowhere". (Note: the thread group leader does not
847 report death via WIFEXITED(status) until there is at least one other
848 live thread. This eliminates the possibility that the tracer will
849 see it dying and then reappearing.) If the thread group leader was
850 still alive, for the tracer this may look as if thread group leader
851 returns from a different system call than it entered, or even
852 "returned from a system call even though it was not in any system
853 call". If the thread group leader was not traced (or was traced by
854 a different tracer), then during execve(2) it will appear as if it
855 has become a tracee of the tracer of the execing tracee.
856 All of the above effects are the artifacts of the thread ID change in
858 the tracee.
859 The PTRACE_O_TRACEEXEC option is the recommended tool for dealing with
861 this situation. First, it enables PTRACE_EVENT_EXEC stop, which occurs
862 before execve(2) returns. In this stop, the tracer can use
863 PTRACE_GETEVENTMSG to retrieve the tracee's former thread ID. (This
864 feature was introduced in Linux 3.0). Second, the PTRACE_O_TRACEEXEC
865 option disables legacy SIGTRAP generation on execve(2).
866 When the tracer receives PTRACE_EVENT_EXEC stop notification, it is
868 guaranteed that except this tracee and the thread group leader, no
869 other threads from the process are alive.
870 On receiving the PTRACE_EVENT_EXEC stop notification, the tracer should
872 clean up all its internal data structures describing the threads of
873 this process, and retain only one data structure—one which describes
874 the single still running tracee, with
875 thread ID == thread group ID == process ID.
877 Example: two threads call execve(2) at the same time:
879 *** we get syscall-enter-stop in thread 1: **
881 PID1 execve("/bin/foo", "foo" <unfinished ...>
882 *** we issue PTRACE_SYSCALL for thread 1 **
883 *** we get syscall-enter-stop in thread 2: **
884 PID2 execve("/bin/bar", "bar" <unfinished ...>
885 *** we issue PTRACE_SYSCALL for thread 2 **
886 *** we get PTRACE_EVENT_EXEC for PID0, we issue PTRACE_SYSCALL **
887 *** we get syscall-exit-stop for PID0: **
888 PID0 <... execve resumed> ) = 0
889 If the PTRACE_O_TRACEEXEC option is not in effect for the execing
891 tracee, the kernel delivers an extra SIGTRAP to the tracee after
892 execve(2) returns. This is an ordinary signal (similar to one which
893 can be generated by kill -TRAP), not a special kind of ptrace-stop.
894 Employing PTRACE_GETSIGINFO for this signal returns si_code set to 0
895 (SI_USER). This signal may be blocked by signal mask, and thus may be
896 delivered (much) later.
897 Usually, the tracer (for example, strace(1)) would not want to show
899 this extra post-execve SIGTRAP signal to the user, and would suppress
900 its delivery to the tracee (if SIGTRAP is set to SIG_DFL, it is a
901 killing signal). However, determining which SIGTRAP to suppress is not
902 easy. Setting the PTRACE_O_TRACEEXEC option and thus suppressing this
903 extra SIGTRAP is the recommended approach.
904 Real parent
906 The ptrace API (ab)uses the standard UNIX parent/child signaling over
907 waitpid(2). This used to cause the real parent of the process to stop
908 receiving several kinds of waitpid(2) notifications when the child
909 process is traced by some other process.
910 Many of these bugs have been fixed, but as of Linux 2.6.38 several
912 still exist; see BUGS below.
913 As of Linux 2.6.38, the following is believed to work correctly:
915 * exit/death by signal is reported first to the tracer, then, when the
917 tracer consumes the waitpid(2) result, to the real parent (to the
918 real parent only when the whole multithreaded process exits). If
919 the tracer and the real parent are the same process, the report is
920 sent only once.
921
923 On success, PTRACE_PEEK* requests return the requested data, while
924 other requests return zero. (On Linux, this is done in the libc wrap‐
925 per around ptrace system call. On the system call level, PTRACE_PEEK*
926 requests have a different API: they store the result at the address
927 specified by data parameter, and return value is the error flag.)
928 On error, all requests return -1, and errno is set appropriately.
930 Since the value returned by a successful PTRACE_PEEK* request may be
931 -1, the caller must clear errno before the call, and then check it
932 afterward to determine whether or not an error occurred.
933
935 EBUSY (i386 only) There was an error with allocating or freeing a
936 debug register.
937 EFAULT There was an attempt to read from or write to an invalid area in
939 the tracer's or the tracee's memory, probably because the area
940 wasn't mapped or accessible. Unfortunately, under Linux, dif‐
941 ferent variations of this fault will return EIO or EFAULT more
942 or less arbitrarily.
943 EINVAL An attempt was made to set an invalid option.
945 EIO request is invalid, or an attempt was made to read from or write
947 to an invalid area in the tracer's or the tracee's memory, or
948 there was a word-alignment violation, or an invalid signal was
949 specified during a restart request.
950 EPERM The specified process cannot be traced. This could be because
952 the tracer has insufficient privileges (the required capability
953 is CAP_SYS_PTRACE); unprivileged processes cannot trace pro‐
954 cesses that they cannot send signals to or those running set-
955 user-ID/set-group-ID programs, for obvious reasons. Alterna‐
956 tively, the process may already be being traced, or (on kernels
957 before 2.6.26) be init(8) (PID 1).
958 ESRCH The specified process does not exist, or is not currently being
960 traced by the caller, or is not stopped (for requests that
961 require a stopped tracee).
962
964 SVr4, 4.3BSD.
965
967 Although arguments to ptrace() are interpreted according to the proto‐
968 type given, glibc currently declares ptrace() as a variadic function
969 with only the request argument fixed. It is recommended to always sup‐
970 ply four arguments, even if the requested operation does not use them,
971 setting unused/ignored arguments to 0L or (void *) 0.
972 In Linux kernels before 2.6.26, init(8), the process with PID 1, may
974 not be traced.
975 The layout of the contents of memory and the USER area are quite oper‐
977 ating-system- and architecture-specific. The offset supplied, and the
978 data returned, might not entirely match with the definition of struct
979 user.
980 The size of a "word" is determined by the operating-system variant
982 (e.g., for 32-bit Linux it is 32 bits).
983 This page documents the way the ptrace() call works currently in Linux.
985 Its behavior differs noticeably on other flavors of UNIX. In any case,
986 use of ptrace() is highly specific to the operating system and archi‐
987 tecture.
988
990 On hosts with 2.6 kernel headers, PTRACE_SETOPTIONS is declared with a
991 different value than the one for 2.4. This leads to applications com‐
992 piled with 2.6 kernel headers failing when run on 2.4 kernels. This
993 can be worked around by redefining PTRACE_SETOPTIONS to PTRACE_OLDSE‐
994 TOPTIONS, if that is defined.
995 Group-stop notifications are sent to the tracer, but not to real par‐
997 ent. Last confirmed on 2.6.38.6.
998 If a thread group leader is traced and exits by calling _exit(2), a
1000 PTRACE_EVENT_EXIT stop will happen for it (if requested), but the sub‐
1001 sequent WIFEXITED notification will not be delivered until all other
1002 threads exit. As explained above, if one of other threads calls
1003 execve(2), the death of the thread group leader will never be reported.
1004 If the execed thread is not traced by this tracer, the tracer will
1005 never know that execve(2) happened. One possible workaround is to
1006 PTRACE_DETACH the thread group leader instead of restarting it in this
1007 case. Last confirmed on 2.6.38.6.
1008 A SIGKILL signal may still cause a PTRACE_EVENT_EXIT stop before actual
1010 signal death. This may be changed in the future; SIGKILL is meant to
1011 always immediately kill tasks even under ptrace. Last confirmed on
1012 2.6.38.6.
1013 Some system calls return with EINTR if a signal was sent to a tracee,
1015 but delivery was suppressed by the tracer. (This is very typical oper‐
1016 ation: it is usually done by debuggers on every attach, in order to not
1017 introduce a bogus SIGSTOP). As of Linux 3.2.9, the following system
1018 calls are affected (this list is likely incomplete): epoll_wait(2), and
1019 read(2) from an inotify(7) file descriptor. The usual symptom of this
1020 bug is that when you attach to a quiescent process with the command
1021 strace -p <process-ID>
1023 then, instead of the usual and expected one-line output such as
1025 restart_syscall(<... resuming interrupted call ...>_
1027 or
1029 select(6, [5], NULL, [5], NULL_
1031 ('_' denotes the cursor position), you observe more than one line. For
1033 example:
1034 clock_gettime(CLOCK_MONOTONIC, {15370, 690928118}) = 0
1036 epoll_wait(4,_
1037 What is not visible here is that the process was blocked in
1039 epoll_wait(2) before strace(1) has attached to it. Attaching caused
1040 epoll_wait(2) to return to user space with the error EINTR. In this
1041 particular case, the program reacted to EINTR by checking the current
1042 time, and then executing epoll_wait(2) again. (Programs which do not
1043 expect such "stray" EINTR errors may behave in an unintended way upon
1044 an strace(1) attach.)
1045
1047 gdb(1), strace(1), clone(2), execve(2), fork(2), gettid(2), sigac‐
1048 tion(2), tgkill(2), vfork(2), waitpid(2), exec(3), capabilities(7),
1049 signal(7)
1050
1052 This page is part of release 3.53 of the Linux man-pages project. A
1053 description of the project, and information about reporting bugs, can
1054 be found at http://www.kernel.org/doc/man-pages/.
1055Linux 2013-07-11 PTRACE(2)