在 PTRACE_ATTACH 之后处于无限等待状态的 waitpid答案

【问题标题】：waitpid in infitine wait state after PTRACE_ATTACH在 PTRACE_ATTACH 之后处于无限等待状态的 waitpid
【发布时间】：2016-10-27 08:26:45
【问题描述】：

我在我的 C++ 应用程序中集成了 Google-Breakpad。现在，我故意让应用程序崩溃，但它在我的 Ubuntu i686 系统中挂起。我必须将printf 放在 Breakpad 的任何地方，以检查它到底挂在哪里。因此，在 breakpad 中，正在创建一个克隆子进程，并且在该进程中 ptrace(PTRACE_ATTACH, pid, NULL, NULL) 后跟 waitpid(pid, NULL, __WALL) 系统调用在每个线程上被调用。一个特定的线程 waitpid 进入无限等待状态，然后我不得不故意终止应用程序。

有谁知道为什么会发生这种情况？为什么这个特定线程waitpid() 处于无限等待状态？有没有相同的解决方案？

谢谢。

【问题讨论】：

您必须提供更多信息。目前尚不清楚你在问什么。我认为 break-pad 支持论坛是提出这个问题的更好地方。
我投票结束这个问题作为离题，因为它对于堆栈溢出来说太宽泛了，并且确实属于 break-pad 支持论坛。
@ShacharShemesh 我已经在breakpad论坛（groups.google.com/forum/#!topic/google-breakpad-discuss/…）问过了。我想我提供了所有必需的信息。只需将其视为没有breakpad的正常问题。我只需要知道waitpid 在ptrace(PTRACE_ATTACH..) 调用一个特定线程之后进入无限等待状态的原因是什么？不像没有人使用 ptrace 和 waitpid 组合。
好主意。那么如果这是一个正常的问题，请随时发布 MCVE。 (stackoverflow.com/help/mcve)

标签： c++14 ptrace google-breakpad

【解决方案1】：

一般来说，PTRACE_ATTACH 不保证进程会报告任何内容。在 PTRACE_ATTACH 之后，waitpid 将仅在以下两种情况之一发生时触发：

被调试者收到一个信号。
被调试者存在。

有些事情就等于其中之一。例如，如果被调试者调用execve，那么在成功执行之后，内核会使其看起来好像被调试者收到了TRAP 信号。

如果这些情况都没有发生，PTRACE_ATTACH 根本没有理由做任何事情。

如果你想让waitpid 返回（比如说，因为你想改变被调试者的状态），那么只需在调用PTRACE_ATTACH 之后向线程发送一个信号。这将保证线程有话要告诉你。

【讨论】：