调用setcontext恢复中断上下文替代return返回SA_SIGINFO信号处理程序时触发段错误的原因排查

这个问题的核心在于：你在信号处理函数中调用setcontext(uc)的行为，和直接return有着本质的底层差异——前者完全绕过了内核为信号处理设计的完整返回流程，导致内核无法正确清理信号处理状态，最终破坏了上下文结构，引发段错误。

具体的底层逻辑拆解 #

当信号触发时，内核会做这些关键操作：

1. 在用户栈（或指定的信号栈）上创建一个信号帧，其中包含了传递给信号处理函数的ucontext_t结构（也就是你拿到的Uctx指针指向的内容），还有内核用来跟踪信号处理状态的元数据。
2. 修改进程的上下文，跳转到你的信号处理函数执行。

当你从信号处理函数正常return时，内核提供的返回 trampoline（比如x86_64上的__restore_rt）会自动完成以下收尾工作：

• 通知内核信号处理已完成，更新内核内部的信号状态
• 弹出栈上的信号帧，把栈指针恢复到信号触发前的位置
• 正确恢复所有上下文（包括通用寄存器、浮点状态、MXCSR寄存器等）

但如果你直接调用setcontext(uc)，相当于直接跳回了信号触发前的执行点，完全跳过了上述内核的收尾流程：

• 栈上的信号帧没有被弹出，会一直留在栈中累积
• 内核无法感知到信号处理已经完成，其内部的信号状态记录会出现异常

为什么第三次信号会触发段错误？ #

当第三次信号到来时，内核会再次在栈上压入新的信号帧。此时栈上已经累积了多个未被清理的旧信号帧，导致ucontext_t结构中的某些关键字段（比如指向MXCSR状态的内存地址）被意外覆盖为0。

从你提供的setcontext汇编代码可以看到，段错误发生在这一行：

0x00007ffff7a341ae <+46>: ldmxcsr 0x1c0(%rdi)

这里%rdi是ucontext_t指针，0x1c0(%rdi)对应的地址已经变成了0，访问空地址自然触发了SIGSEGV。

正确的做法 #

永远不要用setcontext(uc)来模拟信号处理函数的正常返回——这属于绕过内核信号机制的非法操作，行为完全不可预测。如果想要从信号处理函数返回，直接写return即可，内核会自动完成所有上下文恢复和状态清理工作。

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