【发布时间】：2013-05-21 23:52:31
【问题描述】：
我正在编写一个监视系统调用的程序（除其他外）。但是我在让 ptrace 识别我传递给它的进程 ID 时遇到了一些麻烦。执行程序后，我收到以下错误消息：
:No such process
但是，我已经在调用之前验证了进程 ID，方法是将其打印到控制台并使用 ps -all 进行验证。
以下是一些可能相关的代码（如有必要，我可以发布更多）：
领导子进程：
/* Call to be traced */
if (ptrace (PTRACE_TRACEME, 0, 0, 0) < 0){
perror ("Process couldn't be traced");
exit (-1);
}
/* Execute process image */
if (execv (ProcessArgs[0], &ProcessArgs[1]) < 0){
perror ("Couldn't execute process");
exit (-1);
}
在父进程的线程中：
DbgdProcess * _Process = ( DbgdProcess * ) _ProcessPass;
int SystemCall = 0,
Status = 0;
/* I have tried sleep(1) here to wait for PTRACE_ME to no avail */
while (!_Process->CloseSignal){
if ( wait (&Status) < 0) // error handler
if ( WIFEXITED (Status)) // error handler
if (!WIFSTOPPED (Status)) continue;
SystemCall = ptrace (PTRACE_PEEKUSER, _Process->ID, 4 * ORIG_RAX, 0);
if (SystemCall < 0) // error handler
printf ("Process made system call %d\n", SystemCall);
if (ptrace (PTRACE_CONT, _Process->ID, 0, 0) < 0) // error handler
}
有人可以向我解释这种行为吗？
一些额外说明：
- 被调试的进程是父进程的直接子进程
- 我很确定这是一个 64 位编译，因为 sys/reg.h 只定义了 RAX
- 所有错误处理程序都包含 perror() 消息
更新：
我从手册页中读到了这个：
大多数 ptrace 命令（除了 PTRACE_ATTACH、PTRACE_SEIZE、 PTRACE_TRACEME、PTRACE_INTERRUPT 和 PTRACE_KILL）需要被跟踪者 处于 ptrace-stop 中，否则它们会因 ESRCH 而失败。
我相信，ESRCH 给出的信息是“没有这样的过程”。那么，当我进行 ptrace 调用时，进程可能没有被 ptrace 停止？
更新：
我正在测试example 中的代码。在执行以下操作后，我确实让它工作： - 将标头从更新为 - 将 (eax_orig * 4) 更改为 (rax_orig * 8)
但这些更改也在我的程序中，但仍然无法正常工作。
更新：
我的代码正在运行。我不完全确定为什么，但是在我在使用 ptrace(2) 进行轮询调用的同一线程中调用 PTRACE_ATTACH 后它开始工作。我想这意味着 ptrace 必须在父进程的同一线程中使用，但我不完全确定。我现在的问题是，有人知道这是不是真的吗？或者，如果不是，为什么 ptrace 会这样？
更新：
我发现了这个link，这似乎表明我的问题并非闻所未闻。
【问题讨论】：