BDWGC在HP-UX/HP_PA系统上的信号处理问题分析与解决

问题背景

BDWGC（Boehm-Demers-Weiser垃圾收集器）是一个广泛使用的内存管理库。在HP-UX 11系统上运行gctest测试程序时，出现了随机性挂起的问题。这个问题特别出现在32位HP-PA架构上，但64位版本也有偶发情况。

问题现象

测试程序gctest在运行过程中会随机性挂起，主要表现是：

1. 程序输出停留在"Collect from a standalone thread"信息后不再继续
2. 有时会直接崩溃并输出"Signals delivery fails constantly"错误信息
3. 通过gdb调试发现多个线程处于信号等待状态

技术分析

通过分析核心转储文件和线程堆栈，发现了以下关键点：

1. 信号处理机制失效：主线程无法通过信号机制暂停其他线程，导致垃圾收集过程无法完成。

2. fork操作的影响：问题特别容易在fork操作后出现，因为HP-UX系统的pthread_atfork处理程序会阻塞所有信号。

3. 线程状态分析：

   • 线程1和线程4-6都卡在__sigsuspend_sys系统调用中，等待信号
   • 线程2因无法发送信号而调用abort()
   • 线程3在获取锁时被阻塞

4. 根本原因：HP-UX系统在调用fork准备处理程序时，会默认阻塞所有信号，这违反了POSIX标准关于信号处理的规定。这种特殊行为导致BDWGC的信号机制无法正常工作。

解决方案

针对这个问题，开发团队提出了以下修复方案：

1. 在fork准备处理程序中显式解除信号阻塞：在获取锁之前，先调用GC_unblock_gc_signals()函数解除对GC相关信号的阻塞。

2. 条件编译保护：仅在HP-UX系统（定义了GC_EXPLICIT_SIGNALS_UNBLOCK）且支持atfork调用时启用该修复。

具体代码修改如下：

static void fork_prepare_proc(void)
{
#    if defined(GC_EXPLICIT_SIGNALS_UNBLOCK) && defined(CAN_CALL_ATFORK)
  if (GC_handle_fork == 1)
    GC_unblock_gc_signals();
#    endif
  /* 原有锁获取代码 */
}

验证结果

经过修复后：

1. 32位版本测试通过率显著提高
2. 64位版本的偶发问题也得到解决
3. 测试程序能够完整运行所有测试用例

技术启示

这个问题揭示了在不同Unix-like系统上信号处理实现的差异性。开发跨平台系统软件时需要注意：

1. 信号处理是高度系统相关的领域
2. 系统调用如fork的实现可能有特殊行为
3. 多线程环境下的信号处理更加复杂
4. 针对特定平台的适配是必要的

BDWGC通过这种平台特定的修复，保持了其在各种Unix系统上的兼容性和可靠性。这个案例也展示了如何通过深入分析线程堆栈和信号状态来诊断复杂的多线程问题。