BDWGC 在 Android 平台上的罕见无限循环问题分析

问题背景

BDWGC（Boehm-Demers-Weiser Garbage Collector）是一个广泛使用的保守式垃圾回收器。在 Android 平台上，开发者发现了一个罕见的 GC 卡死问题，表现为垃圾回收器在执行过程中陷入无限循环。这个问题与信号处理和线程同步机制密切相关。

问题现象

当系统生成 bug report 时，会向"Signal Catcher"线程发送 SIGQUIT 信号，该线程又会向所有线程发送 SIGRT_1 信号以进行堆栈展开。这种信号传递机制意外干扰了 BDWGC 的线程挂起/恢复机制，导致垃圾回收过程出现异常。

根本原因分析

问题的核心在于 GC_stop_count 的竞争条件和信号处理的时序问题：

1. 线程挂起阶段：所有线程被挂起在 GC_suspend_handler 中，等待在 sigsuspend 调用上。

2. 线程意外唤醒：在 GC 完成并准备重启所有线程时，GC 会先将 GC_stop_count 更新为 GC_stop_count + 1。但在 GC 有机会向其他线程发送重启信号之前，其他线程可能被非 GC 重启信号（如 SIGRT_1）唤醒。

3. 状态不一致：被意外唤醒的线程发现 GC_stop_count != my_stop_count，于是退出 sigsuspend 循环，并将其 last_stop_count 设置为 GC_stop_count | 1。

4. 线程计数错误：GC 线程执行 GC_restart_all 时，误认为这些线程已经启动，不再向它们发送信号，导致 n_live_threads 计数不准确。

5. 信号量问题：n_live_threads 被用于 resend_lost_signals_retry，导致 sem_timedwait 调用次数与 GC_suspend_ack_sem 的实际值不匹配。

6. 无限循环：当 ack_count > n_live_threads 时，系统会陷入无限循环，即使所有线程已成功重启。

解决方案

修复方案主要关注以下几个方面：

1. 线程状态判断：修改线程唤醒条件，确保只有正确的信号能唤醒被挂起的线程。

2. 原子操作保护：使用适当的原子操作来保护关键变量的访问。

3. 信号量同步：确保信号量的获取和释放与线程状态严格同步。

4. 竞态条件处理：增加对意外唤醒情况的处理逻辑。

技术启示

这个案例展示了在多线程环境下信号处理的复杂性，特别是在垃圾回收这种需要精确控制所有线程状态的场景中。开发者需要注意：

1. 信号处理可能在任何时间点中断程序执行，必须考虑所有可能的执行路径。

2. 线程同步机制必须能够处理意外唤醒和信号丢失的情况。

3. 原子操作和内存屏障在多线程编程中的重要性。

4. 在 Android 等复杂环境下，需要考虑系统其他组件可能发送的信号对应用程序的影响。

结论

BDWGC 在 Android 平台上的这个无限循环问题是一个典型的并发编程边界条件问题。通过深入分析信号处理机制和线程同步逻辑，开发者能够理解并修复这类复杂问题。这也提醒我们在设计跨平台系统软件时，必须充分考虑不同操作系统特有的信号处理机制和线程调度行为。