科技 · 实用指南
Linux 提示“Segmentation fault (core dumped)”？重装前先保留崩溃并匹配二进制
冻结一次崩溃记录，找到实际 core 处理器，保留转储，证明可执行文件与库完全匹配，再分析所有线程并用相同负载验收修复。
“Core dumped”不等于当前目录一定有名为 core 的文件。Linux 可能抑制转储、改名、通过管道交给处理器，或由 systemd-coredump 保存在别处。更换软件包、反复重启或重建之前先保留事件。
可靠的事后分析需要同一套匹配证据：保留的 core、发生崩溃的准确可执行字节、映射库和正确符号。最上层帧只是执行停止位置，不一定是内存最初被破坏的位置。
1. 系统变化前冻结一次崩溃
记录 UTC 时间、命令或服务、PID、信号、负载和第一段相关日志，保存准确报错与服务状态，把后续制品绑定到同一事件。
暂不重装、strip、升级或替换可执行文件。若必须恢复服务，先复制并哈希二进制和相关库，记录软件包或容器摘要。
2. 确认实际 core 路由
在崩溃上下文读取 `ulimit -c` 和 `/proc/sys/kernel/core_pattern`。以 `|` 开头的是处理器而非路径；systemd 环境用 `coredumpctl list` 与 `info` 按时间、PID 和可执行文件选中记录。
用 `coredumpctl dump PID --output=core.PID` 导出或保留原文件，同时记录处理器元数据、时间、信号与保留状态。没有转储就写明限制分支，不能伪造事后分析。
3. 把 core 绑定到准确二进制
哈希崩溃程序，并用 `readelf -n` 记录 ELF Build ID；保存软件包、容器摘要和映射库集合。“版本名相同”不足以证明地址相同。
用 `gdb -q /exact/program core.PID` 显式载入。若出现可执行文件、共享库或符号不匹配警告，把它视为证据完整性失败；找回匹配制品，否则停止。
4. 分析所有线程而非只看 frame 0
保存 `info files`、`info sharedlibrary`、`thread apply all bt full`、寄存器和停止指令附近反汇编，注明符号是完整、部分还是缺失。
SIGSEGV 可能源自更早的越界写、释放后使用或竞态。最上层帧只证明停止点；结合线程、输入、所有权和可复现性提出假设，安全时在隔离环境使用调试构建或 sanitizer。
5. 只修一个假设并定义验收
做一处由证据支持且可评审的修改，保留原 core、哈希和记录不变，以便前后对比。
用相同负载与环境重放。验收要求输出正确、没有新的同类 core、服务健康稳定且记录部署 Build ID；仅重启后暂时不报错不算证明。
