async-profiler与RocksDB JNI结合使用时的信号中断问题分析

问题背景

在使用async-profiler对集成了RocksDB JNI和Folly协程的本地应用程序进行性能分析时，发现了一个稳定的崩溃问题。这个崩溃仅在启用性能分析时出现，且仅当应用程序使用Folly的协程功能时才会发生。通过一系列测试发现，即使禁用C栈展开或使用非默认信号，问题依然存在。

问题现象

崩溃时的调用栈显示，问题发生在RocksDB内部，具体是在协程相关的代码路径上。特别值得注意的是，当使用async-profiler的CPU时间分析功能时会出现崩溃，而使用内存分配分析功能时则不会出现崩溃。

问题定位过程

通过逐步排除法，我们首先确认了问题与async-profiler的信号发送机制有关。进一步测试发现，即使使用一个极简的信号发送程序（不包含任何实际分析功能），只要向非JIT编译线程发送信号，就能重现相同的崩溃现象。

这表明问题本质上是应用程序对信号处理的不完善，而非async-profiler本身的缺陷。具体来说，当信号中断某些系统调用时，应用程序没有正确处理EINTR错误码，导致后续执行路径出现问题。

技术原理分析

在Linux系统中，信号处理是一个需要注意的复杂问题。当信号到达时，当前正在执行的线程会被中断，转而执行信号处理函数。处理完成后，线程会从被中断的位置继续执行。在这个过程中，有几个关键点需要注意：

1. 系统调用中断：某些阻塞型系统调用（如poll、read等）在被信号中断后会返回EINTR错误。良好的编程实践应该检查这个错误码并适当重试或处理。

2. 栈空间使用：信号处理函数使用与被中断线程相同的栈空间。如果应用程序存在访问栈指针上方内存的代码，可能会被信号处理函数破坏，导致未定义行为。

3. 可重入性：信号处理函数中应该只使用异步信号安全的函数，避免在信号处理中调用不可重入的函数。

解决方案

经过深入排查，最终确认问题根源是RocksDB中的一个poll系统调用在被信号中断后没有正确处理EINTR错误码。正确的做法应该是在收到EINTR时重新发起poll调用，而不是继续执行后续逻辑。

对于这类问题，开发者可以采取以下预防措施：

1. 对所有可能被中断的系统调用添加EINTR处理逻辑
2. 在关键代码段使用sigprocmask临时屏蔽信号
3. 使用SA_RESTART标志设置信号处理，让内核自动重启被中断的系统调用

经验总结

这个案例展示了性能分析工具与应用程序交互时可能遇到的微妙问题。虽然表面上看起来是分析工具导致了崩溃，但根本原因往往是应用程序本身对信号处理的不完善。作为开发者，我们应该：

1. 充分理解信号处理机制及其对应用程序的影响
2. 在编写可能被中断的代码时考虑重入性和错误恢复
3. 使用工具发现问题后，应该深入分析根本原因而非简单归咎于工具

async-profiler作为一款成熟的性能分析工具，其信号处理机制是经过充分验证的。当遇到类似问题时，建议先使用最小化测试用例验证问题，然后逐步分析应用程序自身的信号处理逻辑。