深入分析 rr 调试器中的僵尸进程卡死问题

问题背景

在 rr 调试器的使用过程中，开发者发现了一个偶发性问题：当使用 rr --wait 命令时，调试器有时会无法正确回收已经退出的子进程，导致 rr 进程自身被永久阻塞而无法退出。这个问题表现为 rr 进程卡住，同时系统中留下了一个僵尸进程。

问题现象分析

通过系统进程状态检查，可以观察到以下情况：

1. 一个 rr 进程（例如 pid 1566）正在运行
2. 该进程有一个僵尸状态的子进程（例如 pid 1675）
3. 僵尸进程实际上有两个线程：
   • 主线程处于僵尸状态（Z）
   • 另一个线程处于跟踪停止状态（t）

进一步使用 gdb 附加到 rr 进程进行分析，发现：

1. rr 仍在跟踪这两个线程
2. 主线程无法被回收，因为另一个线程尚未退出
3. 非主线程处于 PTRACE_EVENT_EXIT 的 ptrace 停止状态
4. rr 进程自身阻塞在 waitid(-1) 系统调用上

根本原因

通过详细的日志分析和代码追踪，发现问题的根本原因在于：

1. 当进程收到异步 SIGSEGV 信号（如通过 tgkill 发送）时，rr 会注入该信号并继续执行
2. 在信号处理过程中，内核需要处理 core dump（如果配置了 core_pattern）
3. 在此期间，rr 会调度其他可运行的任务
4. 关键问题出现：内核会先向非主线程发送 PTRACE_EVENT_EXIT 通知，然后再通知主线程
5. rr 处理主线程的退出通知后，会将其状态设为僵尸
6. 但由于非主线程仍处于 ptrace 停止状态（未被继续执行到僵尸状态），导致主线程无法被回收
7. 最终 rr 陷入永久等待状态

解决方案

修复方案的核心思想是：确保在遇到 PTRACE_EVENT_EXIT 事件时，正确处理所有线程的退出流程。具体包括：

1. 当检测到线程的 PTRACE_EVENT_EXIT 事件时，立即将其标记为已退出
2. 确保所有线程都能被正确继续执行到最终退出状态
3. 避免因线程退出顺序问题导致的死锁情况

技术细节

在 Linux 系统中，线程退出的处理有以下特点：

1. 线程组退出时，内核会向调试器发送 PTRACE_EVENT_EXIT 通知
2. 通知的顺序可能不是固定的（主线程和非主线程的顺序可能变化）
3. ptrace 停止状态需要被显式继续才能使线程真正退出
4. 只有所有线程都退出后，线程组领导者才能被回收

rr 调试器需要妥善处理这些边界情况，特别是在处理信号和核心转储等复杂场景时。

总结

这个案例展示了调试器开发中一个典型的问题：正确处理多线程程序的退出流程。特别是在处理信号和 ptrace 交互时，需要考虑各种边界条件。通过深入分析进程状态、内核行为和调试器内部逻辑，最终定位并修复了这个棘手的僵尸进程问题。

对于使用 rr 的开发者来说，这个修复提高了调试器的稳定性，特别是在处理多线程程序异常退出的场景下。这也提醒我们，在开发类似工具时，需要特别注意线程生命周期管理和 ptrace 事件处理的完备性。