程序偶发 SIGSEGV 崩溃，gdb 显示 best=DBL_MAX 且指针为空——浮点比较"恒不成立"时哨兵从未被覆盖

你会遇到什么

真实案例：MariaDB 5.5.64 在国产 ARM64 服务器（信创早期、CPU 无 FPU）上偶发崩溃，SIGSEGV s=11；gdb 现场 best_key = 0x0（空指针）+ best = DBL_MAX（1.797e+308 哨兵初值，从未被任何候选覆盖）。看起来"偶发"，因为只有数据/环境触发到比较恒 false 时才发生，平时一切正常。

本文路径：快速修复（30 秒一段命令）→ 一步步排查（可跳读）→ 原理与变体（症状/原因/证据）。赶时间直接跳到「快速修复」。

为什么会这样

任何「用 DBL_MAX 做最优初值 + 指针记录最优项」的搜索/选择代码，一旦所有比较都不成立，哨兵不被覆盖 → 指针保持 NULL → 解引用即崩溃。三层原因：

崩溃的传导链是「ABI 错位 → NaN → 比较恒 false → 哨兵未覆盖 → 空指针解引用」：环境层，无 FPU 的 ARM64 按软浮点 ABI 编译系统组件，MariaDB 二进制按硬浮点 ABI，浮点寄存器约定错位，值被读成 NaN/错误值；

机制层，IEEE 754 规定 NaN 参与任何比较恒为 false，if (score < best) 对 NaN 永远不成立，best 保持初始值 DBL_MAX、best_key 保持 NULL；

代码层，使用前未判空——best_key 本就是「有无候选命中」的有效性哨兵。三层缺一不可：没有 ABI 错位就不会产生 NaN，没有 NaN 语义哨兵就会被覆盖，没有代码缺陷就不会崩溃。

确定性推论：崩溃前有浮点运算的搜索/选择代码，先怀疑 NaN 路径；防御写法 = 比较前 isfinite 过滤 + 解引用前判空（if (best_key)）；排查信号 = 值异常（NaN/极大）而不是逻辑错误；判断路径：日志里出现 NaN/Inf 或「第一次就崩」+ 信创 ARM 环境 = ABI 层先查。

一步步来

1. 代码兜底（任何平台都该做） — 必做

浮点比较前过滤非有限值：

if (!isnan(s) && !isinf(s) && s < best) { best = s; best_key = &cands[i]; }

哨兵指针使用前判空：

if (best_key == NULL) { /* 走错误路径/返回"无结果" */ }

可加日志输出 best 值——若出现 DBL_MAX 说明比较从未成功，直接指向浮点层问题。

2. 环境根治：确认浮点 ABI 匹配 — 必做

信创软浮点环境用 -msoft-float 重新编译目标程序（文章解法）。排查：

readelf -A <二进制> | grep -i vfp
ldd <二进制>
grep -i fpu /proc/cpuinfo

看 ARM Tag_ABI_VFP_args 标记、依赖是否混入硬浮点库、CPU 是否真无 FPU。

3. 警惕软浮点库行为 — 必做

软浮点/FTZ 实现常把 denormal 冲成 0（实测 DBL_MIN/2 == 0），极小值比较/分支结果与硬浮点不同；同一套代码在不同 ABI 下行为不一致时，优先怀疑浮点 ABI 而非业务逻辑。

怎么确认修好了

修复版同输入走错误路径不崩溃（实测输出形态）：

isnan 过滤 + best_key == NULL 守卫 → 同输入走错误路径，不崩溃（实测 2）

bug 版：NaN 分数数组 → best 保持 DBL_MAX、best_key 保持 NULL → 解引用 SIGSEGV（实测 1，与文章 dump 逐项一致）。

其它环境的表现

症状

真实案例：MariaDB 5.5.64 在国产 ARM64 服务器（信创早期、CPU 无 FPU）上偶发崩溃，SIGSEGV s=11；gdb 现场 best_key = 0x0（空指针）+ best = DBL_MAX（1.797e+308 哨兵初值，从未被任何候选覆盖）。

泛化特征：任何「用 DBL_MAX 做最优初值 + 指针记录最优项」的搜索/选择代码，一旦所有比较都不成立（NaN 参与、FPU 指令异常、软硬浮点 ABI 错位），哨兵不被覆盖 → 指针保持 NULL → 解引用即崩溃。看起来"偶发"，因为只有数据/环境触发到比较恒 false 时才发生，平时一切正常。

原因

1. 环境根因（文章结论）：信创早期 ARM64 CPU 无 FPU/浮点指令异常 → 系统按软浮点 ABI（-msoft-float）编译运行；MariaDB 二进制按硬浮点 ABI 编译。软浮点程序加载硬浮点二进制/库 → 浮点寄存器约定与运算结果错位 → 浮点值被读成 NaN/错误值。
2. 机制根因（通用）：IEEE 754 下 NaN 参与任何比较恒为 false（NaN < x、NaN >= x 都不成立）。if (score < best) 恒 false → best 保持 DBL_MAX、best_key 保持 NULL。
3. 代码缺陷：使用前未判空/未校验——best_key 本身就是"有无候选命中"的有效性哨兵，但代码直接解引用，没有 if (!best_key) 守卫。

解法

1. 根治（环境）：确认浮点 ABI 匹配。信创软浮点环境用 -msoft-float 重新编译目标程序（文章解法）；排查：readelf -A <二进制> 看 ARM Tag_ABI_VFP_args 标记、ldd 检查依赖是否混入硬浮点库、dmesg | grep -i fpu / grep -i fpu /proc/cpuinfo 确认 CPU 是否真无 FPU。
2. 兜底（代码，任何平台都该做）：

• 浮点比较前过滤非有限值：if (!isnan(s) && !isinf(s) && s < best)——NaN/Inf 不参与"最优"选择；
• 哨兵指针使用前判空：if (best_key == NULL) { 走错误路径/返回"无结果" }，绝不直接解引用；
• 可加断言辅助排查：日志输出 best 值——若出现 DBL_MAX 说明比较从未成功，直接指向浮点层问题。

1. 警惕软浮点库行为：软浮点/FTZ 实现常把 denormal 冲成 0（见验证证据 3），极小值比较/分支结果与硬浮点不同；同一套代码在不同 ABI 下行为不一致时，优先怀疑浮点 ABI 而非业务逻辑。