浮点异常崩溃在多线程下更难定位，因为浮点异常标志是线程局部的，而默认异常掩码是进程级的；需在每个线程入口调用feenableexcept()启用中断，并用volatile防止优化；musl等不支持时应改用SIGFPE handler配合fegetenv/fetestexcept兜底。
浮点异常崩溃为什么在多线程下更难定位
因为 std::feclearexcept 和 std::fetestexcept 是线程局部的，而默认的浮点异常掩码（via fegetenv/feholdexcept）在多数 libc 实现中是进程级的——但线程创建时继承父线程的浮点环境，后续修改互不影响。这意味着：一个线程触发了 FE_DIVBYZERO，若未主动启用异常中断（feenableexcept(FE_DIVBYZERO)），它只会静默设标志；而主线程或 gdb 捕获到的 SIGFPE，往往已丢失上下文，堆栈指向内联汇编或 math 库内部。
必须在启动时为每个线程显式启用浮点异常中断
不要依赖全局设置。Linux 下需用 feenableexcept()（glibc 扩展，非标准但广泛支持），且必须在 每个线程入口函数开头 调用：
#include <cfenv>
#include <thread><p>void worker() {
// 必须放第一行！否则可能漏掉初始化阶段的异常
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);</p>
<pre class="brush:php;toolbar:false;">// 后续计算...
double x = 0.0;
volatile double y = 1.0 / x; // 此处会立即触发 SIGFPE
}
-
feenableexcept()仅对当前线程生效，子线程不继承 - 务必加
volatile或内存屏障防止编译器优化掉可疑计算（如1.0/0.0可能被常量折叠） - 注意：musl libc 不支持
feenableexcept，需改用信号 handler +fegetexcept()轮询（见下一条）
当 feenableexcept 不可用时，用 SIGFPE handler + 环境快照兜底
在 musl、某些嵌入式 STL 或禁用 glibc 扩展的构建中，需手动注册信号处理器，并在 handler 中捕获浮点状态：
void fpe_handler(int sig, siginfo_t* info, void* ucontext) {
fenv_t env;
fegetenv(&env); // 获取当前线程浮点环境快照
int excepts = fetestexcept(FE_ALL_EXCEPT);
if (excepts & FE_DIVBYZERO) {
std::cerr si_addr // 安装（每个线程都要调用）
struct sigaction sa;
sa.sa_sigaction = fpe_handler;
sa.sa_flags = SA_SIGINFO | SA_ONSTACK;
sigaction(SIGFPE, &sa, nullptr);
- handler 内禁止调用任何非异步信号安全函数（
std::cout、malloc、printf全部不行） - 用
sigaltstack配合SA_ONSTACK防止 handler 栈溢出（尤其递归浮点异常） -
si_addr在除零时通常为空，真正有用的是通过ucontext解析寄存器获取指令指针（需平台相关代码）
gdb 调试时必须关闭编译器浮点优化并启用符号
否则 bt 显示的帧可能是内联后的 math 函数，或变量被优化掉：
- 编译加
-O0 -g3 -fno-unsafe-math-optimizations -fno-finite-math-only - gdb 中先
handle SIGFPE stop print，再run—— 这样崩溃时停在触发指令行，而非 signal handler 入口 - 用
info registers查mxcsr（x86-64）或fpscr（ARM）确认异常标志位，比依赖 C++ 层代码更可靠 - 若使用 Intel MKL 或 Eigen，记得链接时加
-lm并确认其未覆盖浮点环境（某些 BLAS 实现会悄悄调用feupdateenv）
线程局部浮点状态和信号处理的耦合，让问题总在最不希望它出现的时候丢掉关键现场——每次新线程创建，都得把它当成浮点异常的“犯罪现场”重新布防。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
