Question

我正在编写一个监视系统调用的程序（以及其他内容）。但我在让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）需要跟踪处于停靠状态，否则他们会因ESRCH而失败。

ESRCH，我相信，给出的信息是“没有这样的过程”。因此，当我进行ptrace调用时，这个过程可能不是ptrace停止的吗？

更新

我正在测试此example中的代码。在执行以下操作后，我确实让它工作了： - 将标题更新为a - 将（eax_orig * 4）更改为（rax_orig * 8）

但是，这些变化也是在我的计划中，它仍然无效。

更新

我的代码正常运行。我不完全确定为什么，但是在我使用ptrace（2）进行轮询调用的同一线程中调用PTRACE_ATTACH之后它开始工作了。我想这意味着ptrace必须在父进程的同一个线程中使用，但我不完全确定。我现在的问题是，有谁知道这是真的吗？或者，如果没有，为什么ptrace会这样做？

更新

我发现了这个link，这似乎表明我的问题并非闻所未闻。

Answer 1

睡眠（1）有时是不够的;试着睡觉（5）。

Answer 2

在检查进程是否已停止之前，为什么要进行PTRACE_SYSCALL？

理想情况下，在父线程中，您应该等待孩子停止使用等待。

一旦孩子停止使用WIFSTOPPED，则只使用任何其他ptrace调用。

看来PTRACE_SYSCALL正在返回ESRCH。你能确认吗

PTrace不承认儿童过程

2 个答案: