操作系统内功 · 第 53 篇｜Core dump 尸检指南：core_pattern、ELF core 与事后分析

为什么尸检不可替代

第 12 篇讲过 ptrace：调试器附着在活进程上断点单步，是活体解剖。这一篇讲它的镜像场景——死后分析。崩溃往往在最不该发生的时候发生：客户环境偶现一次、生产高峰深夜炸一回、复现要凑齐特定并发时序。现场即焚的世界里，core dump 是唯一能保存下来的证据：进程崩溃的瞬间，内核把它完整的地址空间——寄存器、每个线程的栈、堆、加载的模块映射——按标准格式写成文件。只要这份文件在，事后的任何一个工作日，工程师都可以用调试器回到崩溃的那一毫秒，看每一个变量的值、每一条调用栈。

尸检的价值不限于段错误。内存越界写坏的堆结构、断言失败时的不变量状态、死锁时各线程卡住的锁地址、内存泄漏到临界点时的分配分布，全都凝固在 core 里。一次高质量的尸检常常同时回答三类问题：直接死因（哪条指令、哪个信号）、传导链条（谁调用的、什么状态下的分支）、以及环境背景（哪个版本、哪些库、什么配置）。这三维证据在日志里往往只有残片，在 core 里却是完整切面。

工程上要让尸检可用，有两个前置条件必须提前部署好，事后再配就晚了：其一，core 的生成开关与落地路径在生产环境统一配置好；其二，带符号的二进制与调试信息归档保存（版本与发布一一对应）。后者常被忽视：core 里全是地址，没有符号就是一堆十六进制天书。版本管理纪律与 core 管理纪律，是一对必须成对出现的工程习惯。

尸检与日志的关系也值得摆正。日志是应用自己写的叙述，崩溃瞬间恰恰是叙述中断的时刻——最后一行日志之后发生了什么，日志永远回答不了；core 补上的正是这段空白。两者是互补关系：日志给时间线，core 给横截面，交叉对照才能还原完整事故。实践中有团队在捕获致命信号时先抢写一条「最后遗言」日志再放行崩溃，这层努力与 core 不冲突——遗言给方向，尸检给证据。把 core 纳入可观测性版图而非「调试的附属品」，是很多团队观测成熟度的分水岭。

core 的产生链路：ulimit、core_pattern 与 systemd

链路的第一环是资源限额。进程收到无法处理的致命信号——段错误的 SIGSEGV、断言失败主动 abort 的 SIGABRT、总线错误的 SIGBUS、算术异常的 SIGFPE——内核在终止进程前会检查两件事：这个进程允许转储吗（RLIMIT_CORE 限额是否为零）、转储写到哪里（core_pattern 配置）。限额即第 54 篇要讲的 rlimits 之一，shell 里 ulimit -c 查看，0 表示禁止转储，unlimited 表示不限大小；systemd 服务由单元文件里的 LimitCORE 控制。生产环境最经典的事故是限额为零导致内核认为「该进程不想要 core」而静默跳过——程序崩溃了，却什么都没留下。

第二环是落盘策略，核心配置是 /proc/sys/kernel/core_pattern，它是内核全局参数。最简单的形式是一个绝对路径加模板变量：可执行名、进程号、信号号、时间戳、主机名等占位符在生成时被替换，方便按次归档。更强大的形式是管道模式：pattern 以竖线开头时，内核把 core 内容像写文件一样喂给管道后面指定的外部程序——主流发行版的默认配置正是把 core 交给 systemd-coredump，由它压缩存档到 /var/lib/systemd/coredump，配套的 coredumpctl 命令可以列出历史 core、直接调起 gdb 尸检最近一次崩溃，甚至从 journal 里关联到崩溃当天的日志。管道模式还有一个并发护栏参数（core_pipe_limit），防止大量进程同时崩溃、并发转储把内存与磁盘瞬间打爆。

多线程与子进程的行为也要知道：core 转储覆盖进程的全部线程——每个线程的寄存器组与栈都在其中，正是多线程死锁取证的基础；子进程崩溃则各自独立转储，core 只属于崩溃的那个进程。还有两个易踩的细节：core 文件名里含可执行名时，超长路径可能被截断；以管道模式投递时，内核以 root 身份启动收集程序，收集程序自身的健壮性成为故障面——收集器挂了，core 就静默丢失，所以生产上要定期演练「造一次崩溃、验一次归档」。

权限与安全也要过一遍。core 里包含内存全部内容——密码、密钥、用户数据都在其中，它的安全等级等同于进程本身的内存转储：存储要加密或限制访问、过期要清理、跨环境传输要走审批。管道模式的一个附带好处正是权限收口：core 不落各处散盘，统一进收集器的受控存储。合规审计里 core 管理是常客，提前把保留期限、加密策略、访问白名单写成制度，比出了泄漏再补救体面得多。

ELF core 里有什么

core 文件本身是 ELF 格式，但和普通可执行文件的内容组织不同。第一类内容是注释段里的进程元数据：每个线程一组通用寄存器快照（调试器据此还原各线程停在哪个指令、栈帧在哪）、进程整体信息（可执行路径、命令行、信号来源与触发的信号编号）、辅助向量（内核递给运行时的环境参数）。第二类内容是一段段内存快照：匿名内存、写时复制的私有页、以及文件映射中被修改过的脏页，都以加载段的形式被逐一记录。每个段带虚拟地址范围与权限，调试器按崩溃现场的页表语义重组出完整的地址空间视图。

大小的直觉由此而来：core 的体积近似等于进程崩溃时刻的实际内存占用（写过页的总和），所以一个几十 GB 的数据库进程，core 也是几十 GB 量级。这解释了生产上的两条惯例：其一，给 RLIMIT_CORE 设上限或直接走管道流式压缩，防止连环崩溃把磁盘写满；其二，转储范围可配置（现代内核与调试器支持过滤共享库的只读映射，体积能显著缩小），但过滤越狠、可还原的信息越少，权衡要做在事前而不是崩溃后。

与 core 配套的第三块拼图是符号。生产二进制通常剥离了调试信息，尸检时要用归档的带符号版本（或调试信息包）对照；gdb 加载 core 时指定的可执行文件必须与崩溃版本完全一致——差一个编译，栈回溯就可能错位。纪律严明的团队会把「带符号构建产物按版本归档、core 按版本检索」做成发布流程的一部分，尸检效率由此天差地别。

文件格式层面的知识还有一处实用价值：判断 core 是否完整。转储中途磁盘写满、进程被二次终止、收集器超时，都会留下残缺的 core；调试器打开残缺文件会在加载段时报错或栈回溯异常。快速体检的方法是核对注释段里的线程数与内存段总数是否自洽、文件尺寸与崩溃进程的体量是否量级相符。管道模式下收集器通常自带完整性校验（压缩包的尾部标记），这也是生产上倾向管道收集的又一理由——原始文件模式的完整性要靠运维自己把关。

gdb 尸检实操与两个案例

基本流程三条命令起步：用 gdb 同时指定可执行文件与 core 文件打开现场；bt 看崩溃线程的调用栈；thread apply all bt 展开所有线程的栈。常用进阶动作：bt full 把每一帧的局部变量一并打出；info threads 列线程状态；frame 加编号选中某一帧后用 info locals 与 print 深查变量；info sharedlibrary 对照各共享库的加载版本；disassemble 反汇编崩溃点附近的指令，配合寄存器值定位非法地址的来源。

案例一，段错误定位。栈顶显示崩在一次内存拷贝里，目的地址与某个缓冲区指针一致，往上翻一帧发现这个指针来自一个早已 free 的对象——典型的释放后使用。再 print 一把相关结构，字段值是熟悉的重复填充模式，印证内存已被复用覆盖。这类问题活体调试几乎必现不了（free 之后的时机难以踩准），core 却把现场原样封存。案例二，多线程死锁。bt 展开所有线程：三个工作线程全部停在互斥锁等待（栈上表现为 futex 等待调用，参数里带着同一个锁地址），主线程在等它们的结果。锁地址重复出现就是死锁的直接证据，再结合各线程等待的锁与持有的锁交叉对照，锁序颠倒的环就画出来了。

生产落地再补三条经验。第一，崩溃栈只有两三个帧、且全部落在可疑地址时，先怀疑符号不匹配，换归档的正确版本再回溯，别急着怀疑程序。第二，core 打不开、报内存段缺失时，检查是否用了裁剪版转储或不同架构的 gdb。第三，把「gdb 打开、bt、thread apply all bt、关键字搜索锁地址」做成模板脚本，值班同学照着执行就能产出第一手尸检报告，专家再深度下钻——尸检能力要普及，不能只属于少数人。

死锁取证的效率还可以再抬一档。全线程栈里区分「锁等待」与「IO 等待」是第一动作：前者栈顶是锁等待原语，后者是读写调用；把所有锁等待线程的锁地址汇总去重，出现两个以上互为依赖的地址环，死锁实锤。再往上找「持锁不放」的线程——它不在锁等待栈里，却在调用链上持有着那个人人等待的地址——真凶往往是它在锁内做了一次慢 IO 或回调。这套手法不需要任何额外工具，全线程栈加锁地址交叉表就能完成，值得写成团队的尸检标准流程。

容器里的 core 去哪了

容器是 core 管理的重灾区，经典悬案是「core 文件明明生成了却找不到」。原因在命名空间与文件系统的错位：core_pattern 是内核全局参数，所有容器共享一份——容器里配置的绝对路径按宿主机视角解释，再叠上容器文件系统的挂载映射，路径常常对不上号。容器内 ulimit 又默认可能为零，内核直接跳过转储，连生成的机会都没有。三个因素叠加，core 在容器里失踪是常态而非意外。

工程上的标准解法是宿主机统一接管：宿主机把 core_pattern 配成管道模式，交给 systemd-coredump 或自研收集器统一归档，容器内的崩溃顺着全局配置流到宿主机，用容器标识字段区分归属；同时由运行时给容器内的进程设置合理的 core 限额。退而求其次的方案是给容器挂载专用卷并在 core_pattern 里写死宿主机可达的路径——但这条路径对所有容器生效，多容器环境下要靠模板变量区分，配置复杂度不低。无论哪种方案，「造崩溃、验归档」的演练都不可省：core 链路的每一环都是静默失败的高发区，不演练等于没有。

小结

core dump 是崩溃瞬间的完整地址空间快照：寄存器、全部线程栈、堆与映射一并封存，是偶现故障唯一可靠的证据形态。它的产生链路三环相扣——限额放行、全局 core_pattern 决定落盘方式、管道模式交由收集器归档——任何一环静默失败，尸检就无从谈起。

尸检的实操有固定套路：bt 看栈、thread apply all bt 看全貌、锁地址交叉对照画死锁环、符号版本对齐保回溯准确。容器环境的答案是宿主机统一接管加定期演练，配置了不等于可用，验证过的才算数。

把 core 管理当发布流程的一部分来做：限额与路径部署时就配好、带符号构建按版本归档、尸检脚本模板化普及到值班层。崩溃不可怕，可怕的是崩溃了却两手空空——这便是尸检指南的全部要义。

最后给一条组织层面的建议：给尸检产出建立案例库。每次尸检的栈快照、死因结论、修复提交号三件套归档，半年积累下来就是一部团队专属的故障百科——新人入职先读案例库，比任何培训都快；同类崩溃再次出现时，检索命中率往往高得惊人。证据会过期，方法论不会，案例库让每一次崩溃的成本沉淀为组织的资产。