如何判定SIGSEGV是否由栈耗尽而非其他程序bug触发

不存在严格符合POSIX标准、跨所有兼容系统100%无误差的判定方法，但在Linux、macOS、主流BSD系统上，通过组合多层校验规则，可以做到误判率足够低，完全满足生产环境的使用需求。

必要前置准备 #

你首先要给SIGSEGV信号处理函数配置独立的备用栈，否则栈耗尽时信号处理函数没有可用栈空间，会直接触发二次故障导致进程静默崩溃，根本跑不到你的处理逻辑：

• 调用sigaltstack()注册一块提前分配好的内存作为备用信号栈
• 注册信号处理函数时用sigaction()接口，带上SA_SIGINFO和SA_ONSTACK标志，这样处理函数可以拿到故障详情、运行在备用栈上

核心判定逻辑 #

栈耗尽触发SIGSEGV的本质，是程序访问了线程栈增长方向边界外的警戒页（Guard Page，内核为了检测栈溢出特意预留的未映射内存页），和普通野指针、内存越界、写只读内存等bug触发的SIGSEGV有明确可区分的特征，你可以按以下顺序校验，全部满足就可以判定为栈耗尽：

• 校验故障类型：从信号处理函数入参的siginfo_t结构中读取si_code字段，栈溢出触发的故障一定是访问未映射页，对应值为SEGV_MAPERR；如果值是SEGV_ACCERR（访问权限不匹配，比如写只读代码段），直接判定为普通内存bug。
• 校验故障地址位置：读取siginfo_t的si_addr字段，这就是触发页错误的内存地址，判断这个地址是否落在当前线程栈的警戒页范围内：
  • Linux平台：主线程可以解析/proc/self/maps找到标记为[stack]的内存映射区间，子线程解析对应tid的/proc/self/task/<tid>/maps找到线程栈区间；栈默认向低地址增长，栈区间最低地址往下紧邻的1个内存页就是警戒页，判断si_addr是否落在这个页的地址范围内即可。
  • macOS/BSD平台：直接调用pthread_get_stackaddr_np()和pthread_get_stacksize_np()拿到当前线程的栈基址和大小，按同样的逻辑计算警戒页地址范围即可，不需要解析proc文件。
• 校验栈指针位置（关键防误判层）：从信号处理函数入参的ucontext_t结构中，读取故障发生时的栈指针寄存器值（x86_64对应REG_RSP、x86对应REG_ESP、arm64对应REG_SP）。栈溢出发生时，栈指针一定已经非常接近栈的边界、甚至已经踏入警戒页范围；如果是普通野指针访问到了警戒页地址，栈指针一定还停留在正常栈映射的区间内，这一层校验可以过滤掉99.99%以上的误判场景。

注意事项 #

• 信号处理函数运行在备用栈上，只能调用异步信号安全的系统调用，不要用printf这类标准IO函数，直接用write()往标准错误输出写提示信息，写完调用_exit()直接退出进程即可，不要尝试从信号处理函数返回——栈已经耗尽的情况下，返回故障点会重复触发SIGSEGV。
• 对于你写的递归下降解析器场景，最可靠的方案永远是在解析逻辑里加递归深度计数器：每进入一层递归就给计数器加1，退出时减1，计数器超过预设安全阈值（比如默认8M栈下设置1024或2048层的阈值，留足安全余量）时，直接在正常业务逻辑里抛出"嵌套过深，请使用大栈模式启动"的错误，这个方案零误判、不依赖系统特定的信号机制，比信号兜底方案可靠得多，信号处理只需要作为最后一道防线即可。

误判场景说明 #

唯一可能出现误判的极端情况是：野指针刚好指向栈警戒页的地址，同时故障发生时栈指针刚好也跑到了栈的最边界，这种情况在正常程序中出现的概率可以忽略，不需要额外处理。不要尝试把内存映射到紧邻线程栈的位置，避免人为制造冲突。

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