Notcurses项目在Alpine系统上的信号栈与线程取消问题分析

问题背景

Notcurses是一个用于构建现代终端用户界面的C语言库。在Alpine Linux系统上运行时，出现了程序崩溃的问题，表现为线程在取消过程中发生段错误(Segmentation Fault)。经过深入分析，发现这与信号栈设置和线程取消机制密切相关。

现象描述

在Alpine系统上运行Notcurses程序时，会出现以下典型现象：

1. 程序启动后，输入线程(Thread 2)在执行ppoll系统调用时收到SIG33信号
2. 主线程(Thread 1)尝试通过pthread_timedjoin_np等待输入线程结束
3. 输入线程随后发生段错误，导致程序崩溃

通过gdb调试发现，崩溃发生在musl libc的__cp_end汇编代码处，这是线程取消机制的关键路径。

技术分析

信号栈设置问题

Notcurses中有一个setup_alt_sig_stack函数，其目的是为线程设置替代信号栈。这个实现存在几个潜在问题：

1. 共享信号栈：代码尝试让多个线程共享同一个替代信号栈，这在多线程环境下是不安全的。POSIX标准并未明确规定替代信号栈是否可以在线程间共享。

2. 栈大小不足：当前实现使用SIGSTKSZ*4(约32KB)作为信号栈大小。对于复杂的信号处理场景，这可能不够，特别是在线程取消过程中需要处理额外上下文时。

3. musl特性：Alpine使用musl libc，其信号处理实现与glibc有所不同。musl对信号栈的管理更为严格，共享信号栈可能导致未定义行为。

线程取消机制

musl libc的线程取消实现采用了一种特殊机制：

1. 当线程被取消时，会通过SIGCANCEL信号(内部映射为SIG33)触发取消流程
2. 信号处理需要在当前线程的栈上分配空间保存上下文
3. 如果栈空间不足(由于替代信号栈太小或设置不当)，就会导致段错误

根本原因

综合来看，问题的根本原因是：

1. 共享的替代信号栈在多线程环境下不安全
2. 信号栈大小不足以处理线程取消时的上下文保存需求
3. musl libc对此类错误更为敏感，直接表现为段错误

解决方案

针对这个问题，可以采取以下改进措施：

1. 移除共享信号栈：每个线程应该有自己的替代信号栈，避免多线程竞争。

2. 增加信号栈大小：根据实际需求评估合适的信号栈大小，确保能容纳线程取消时的上下文。

3. 改进错误处理：在sigaltstack调用后检查返回值，确保信号栈设置成功。

4. 线程特定初始化：将信号栈设置移到线程创建时进行，而非在线程函数内部。

经验总结

这个案例提供了几个有价值的经验教训：

1. 信号处理在多线程程序中需要格外小心，特别是涉及替代信号栈时。

2. 不同C库(glibc vs musl)在实现细节上可能有显著差异，跨平台开发时需要充分测试。

3. 线程取消机制实现复杂，需要确保有足够的栈空间处理取消信号。

4. 资源(如信号栈)在多线程间的共享需要谨慎评估，避免隐式共享导致的竞争条件。

通过解决这个问题，Notcurses在Alpine系统上的稳定性得到了显著提升，同时也为类似的多线程信号处理场景提供了有价值的参考。