运行基于Seastar的程序时GDB触发SIG35信号，是否需要担忧？

1. SIG35是否为需要处理的异常 #

SIG35属于Linux系统的实时信号，这个信号在Seastar框架中是正常的内部调度信号，不需要你额外处理：

• x86_64架构的Linux系统中，glibc封装的实时信号起始值SIGRTMIN为34，Seastar默认用SIGRTMIN+1即SIG35作为reactor线程的唤醒信号，用于在线程间投递任务时唤醒阻塞的reactor，属于框架内部正常的逻辑实现。
• 你回溯栈里看到信号触发在Botan的执行流程，只是因为信号投递的瞬间，当前reactor线程刚好在执行RSA素数生成的CPU密集计算，和你的TLS逻辑、RNG线程安全性没有关联。
• GDB默认会拦截所有实时信号并中断执行，所以才会出现你看到的报错，本身不是程序抛出的异常。

2. 排查定位步骤 #

第一步：验证信号为Seastar内部信号 #

在GDB中执行如下命令，配置GDB不拦截该信号：

handle SIG35 nostop noprint pass

之后继续运行程序，如果程序没有出现崩溃、业务逻辑异常，就可以完全确认是GDB拦截框架内部信号导致的误报，不需要做任何代码修改。

第二步：异常场景排查 #

如果配置上述规则后程序仍然出现异常，可以按照如下方向排查：

• 检查代码中是否自行注册了SIG35的信号处理函数，Seastar已经内置了该信号的处理逻辑，上层业务不允许再占用该信号，否则会导致框架调度异常。
• 检查当前RSA证书生成逻辑的执行位置：你当前是在reactor线程中实时生成RSA私钥，属于典型的长时间CPU密集型任务，会阻塞reactor线程的事件循环，轻则导致服务性能下降、请求超时，重则可能触发框架内部调度逻辑异常。建议将这类计算任务移到Seastar的异步工作线程中执行，不要阻塞reactor线程。
• 可通过perf、systemtap等工具追踪信号来源，确认信号是否确实由Seastar框架发出，排除其他进程/线程误发信号的可能性。

额外优化建议 #

你当前在TLS握手阶段实时生成RSA证书的逻辑性能极差，2048位RSA密钥生成即使在高性能CPU上也需要几十毫秒，完全无法支撑高并发场景。建议改为预生成证书缓存，或者提前异步生成证书备用，不要在握手路径上同步生成。

内容的提问来源于stack exchange，提问作者jeffbRTC