rr调试器中SIGSTOP/SIGCONT信号处理的多线程问题分析

在rr调试器的使用过程中，我们发现了一个关于SIGSTOP和SIGCONT信号在多线程环境下处理的边界情况问题。这个问题会导致调试器在特定场景下出现断言失败，影响正常使用。

问题现象

当使用rr记录一个多线程程序时，如果程序执行以下操作序列：

1. 创建子线程并阻塞在pause()系统调用
2. fork子进程
3. 主线程向自己发送SIGSTOP信号
4. 子进程向父进程发送SIGCONT信号

大约有30%的概率会导致rr调试器在记录过程中断言失败，错误信息为"Assertion `is_stopped_' failed to hold"。

问题根源分析

通过深入分析，我们发现问题的本质在于rr调试器对线程状态的管理与内核实际行为之间存在差异。具体来说：

1. 当主线程发送SIGSTOP信号时，rr会模拟一个组停止(group stop)状态
2. 但实际上，只有主线程真正进入了ptrace停止状态，而阻塞在pause()的子线程仍然处于系统调用阻塞状态
3. 当收到SIGCONT信号后，rr尝试恢复所有线程的执行，包括那些实际上并未被停止的线程

技术细节

在Linux内核中，信号处理有以下特点：

1. SIGSTOP信号会发送给整个线程组，但实际停止行为取决于线程状态
2. 阻塞在系统调用中的线程不会被ptrace停止
3. 内核在收到SIGCONT后，可以自由选择恢复线程的顺序，不一定是主线程优先

rr调试器原本假设所有线程都会在SIGSTOP时进入停止状态，这与实际内核行为不符，导致了断言失败。

解决方案

经过讨论，我们采用了最直接的修复方案：在模拟SIGCONT信号处理时，只对那些确实处于停止状态的线程调用resume_execution()。这种方案：

1. 尊重内核的实际行为，不强制要求所有线程都处于停止状态
2. 保持了rr调试器记录的正确性
3. 不会影响正常的调试功能

验证与测试

为了确保修复的有效性，我们编写了一个确定性重现的测试用例，可以100%复现该问题。测试用例通过以下步骤验证修复：

1. 创建子线程并阻塞在pause()
2. 主线程发送SIGSTOP给自己
3. 外部进程发送SIGCONT给主线程
4. 验证rr调试器能够正确处理这种场景

测试结果表明，修复后的rr调试器能够正确处理这种边界情况，不再出现断言失败。

总结

这个问题的解决过程展示了调试器开发中需要特别注意的细节：调试器对程序状态的模拟必须与内核实际行为保持严格一致。特别是在处理信号和多线程交互时，需要考虑各种边界情况。通过这次修复，rr调试器在信号处理方面的健壮性得到了进一步提升。