很抱歉，我无法发布代码来重现此内容。我的问题恰恰是我不知道如何去调试这个问题。

我正在使用 ptrace 和 PTRACE_O_TRACEFORK | PTRACE_O_TRACEEXEC | PTRACE_O_TRACEVFORK | PTRACE_O_TRACEVFORKDONE | PTRACE_O_TRACECLONE 跟踪进程及其子进程(以及子进程的子进程)。该机制很像 strace，但用途略有不同，因为我只是跟踪被读取或修改的文件。

我的代码(用 C 语言编写)在 x86-64 架构的 Debian wheezy 和 Debian jessie 上运行良好(在 i386 上测试较少)。当我尝试在 Ubuntu Precise x86-64 虚拟机(使用 3.2.0 内核)上编译和运行时，我遇到了麻烦。

在 Precise 机器上，我有时发现在 vfork 调用发生后我没有立即收到 PTRACE_EVENT_VFORK，而是开始接收事件(几个 SIGSTOP 事件和一些系统调用)，而没有得到 PTRACE_EVENT_VFORK 事件。我没有看到正在执行的系统调用有任何可疑之处，而且行为是不可预测的。

我不确定如何尝试将这种情况减少到最少的错误情况，而且我真的不知道可能出了什么问题，因为我以前从未见过这种丢失事件的行为。可以想象，区别不是内核，而是我正在跟踪的构建工具(它是 python + gcc 的组合)。

有什么建议吗？

最佳答案

我最近在做类似的事情。我怀疑你很久以前就解决了你的问题或者放弃了，但让我们在这里写一个答案以供后代使用。

您使用 PTRACE_SETOPTIONS 注册的各种事件生成的消息不同于普通的 ptrace 事件。但是正常事件仍然会产生。一个正常事件是新 fork 的进程开始停止并且必须从跟踪器继续。

这意味着如果您注册了使用 PTRACE_O_TRACEFORK(或 VFORK)观看的事件，waitpid 将在 fork 后为同一进程触发两次。

一个人的状态是:

WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == SIGSTOP)

另一个将与:

WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == 0) &&
    ((status >> 16) == PTRACE_EVENT_FORK) /* or VFORK */

内核似乎无法保证它们到达的顺序。我发现它在我的系统上接近 50/50。

为了处理这个问题，我的代码看起来像这样:

static void
proc_register(struct magic *pwi, pid_t pid, bool fork) {
    /*
     * When a new process starts two things happen:
     *  - We get a wait with STOPPED, SIGTRAP, PTRACE_EVENT_{CLONE,FORK,VFORK}
     *  - We get a wait with STOPPED, SIGSTOP
     *
     * Those can come in any order, so to get the proc in the right
     * state this function should be called twice on every new proc. If
     * it's called with fork first, we set the state to NEW_FORKED, if
     * it's called with STOP first, we set NEW_STOPPED. Then when the
     * other call comes, we set the state to TRACED and continue the
     * process.
     */
    if ((p = find_proc(pwi, pid)) == NULL) {
            p = calloc(1, sizeof(*p));
            p->pid = pid;
            TAILQ_INSERT_TAIL(&pwi->procs, p, list);
            if (fork) {
                    p->state = NEW_FORKED;
            } else {
                    p->state = NEW_STOPPED;
            }
    } else {
            assert((fork && p->state == NEW_STOPPED) || (!fork && p->state == NEW_FORKED));
            p->state = TRACED;
            int flags = PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT|PTRACE_O_TRACEFORK|PTRACE_O_TRACEVFORK;

            if (ptrace(PTRACE_SETOPTIONS, pid, NULL, flags))
                    err(1, "ptrace(SETOPTIONS, %d)", pid);
            if (ptrace(PTRACE_CONT, pid, NULL, signal) == -1)
                    err(1, "ptrace(CONT, %d, %d)", pid, signal);
    }
}
[...]
    pid = waitpid(-1, &status, __WALL);
    if (WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == SIGSTOP)) {
            proc_register(magic, pid, false);
    } else if (WIFSTOPPED(status) && (WSTOPSIG(status) & 0xff == 0) && ((status >> 16) == PTRACE_EVENT_FORK)) {
            proc_register(magic, pid, true);
    } else {
            /* ... */
    }

完成这项工作的关键是在我们收到两个事件之前不要发送 PTRACE_CONT。在弄清楚这是如何工作时，我发送了过多的 PTRACE_CONT 并且内核愉快地接受了它们，有时甚至导致我的进程在 PTRACE_EVENT_FORK 到达之前就退出了。这使得调试变得非常困难。

注意我还没有找到任何关于此的文档或任何说明这是应该的方式的文档。我刚刚发现这让事情像今天一样运作。 YMMV.

关于c - 运行 ptrace 时偶尔会丢失 PTRACE_EVENT_VFORK，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29997244/