rr调试器在跟踪Firefox时出现进程退出检测问题分析

问题背景

rr调试器是一款强大的确定性调试工具，但在某些情况下跟踪Firefox浏览器时会出现异常挂起现象。具体表现为当Firefox通过mach mochitest或mach run命令运行时，rr会卡住并持续等待一个实际上已经退出的进程。

现象描述

当问题发生时，rr的进程树会显示多个压缩线程仍在运行，但主调试进程似乎陷入了无限等待状态。通过日志分析发现，rr持续报告某个特定进程(如1776030或1810308)正在等待退出，但实际上系统进程列表中该进程已经不存在。

日志分析

从调试日志中可以观察到几个关键现象：

1. rr不断报告"Task event is SYSCALL: futex"和"still blocked"消息
2. 目标进程状态最终变为FATAL-SIGKILL(0x9)
3. 尽管进程已被终止，rr仍持续检查该进程状态
4. 系统显示所有任务都被阻塞，rr无法找到可运行的任务

问题根源

深入分析代码后发现，问题出在Scheduler.cc文件中的任务可运行性检查逻辑。当rr等待一个进程通过ptrace退出时(waiting_for_ptrace_exit为true)，即使该进程已被回收(was_reaped为true)，rr仍会继续检查其状态，导致无限循环。

解决方案

通过修改Scheduler.cc中的条件判断逻辑，在检查等待退出的进程时，同时验证该进程是否已被回收。具体修改为：

if (t->waiting_for_ptrace_exit && !t->was_reaped()) {
    LOGM(debug) << "  " << t->tid << " is waiting to exit; checking status ...";
}

这一修改确保当进程已被回收时，rr不会继续无谓地检查其状态，从而避免了挂起问题。

验证结果

修改后进行了多项测试验证：

1. rr replay -a功能恢复正常
2. 完整测试套件(ctest -j60)基本通过
3. 偶发的seccomp_desched测试失败在重试后通过
4. 系统稳定性良好，未出现严重副作用

技术启示

这个问题揭示了rr在处理进程状态转换时的一个边界条件缺陷。在实现调试器时，必须仔细考虑所有可能的进程生命周期状态组合，特别是当涉及ptrace系统调用和信号处理等复杂场景时。同时，这也展示了日志分析在诊断复杂调试问题中的重要性。

对于rr用户来说，当遇到类似挂起问题时，可以尝试通过设置RR_LOG=all:debug环境变量来获取更详细的调试信息，这有时能帮助识别问题根源或暂时规避问题。