8、Core Dump分析：从崩溃现场还原真相
程序崩溃了，你慌不慌？
说实话，我早年遇到段错误时，第一反应就是加printf。加完重新编译，跑一遍，崩了，再换个地方加printf。折腾半天，问题没找到，代码倒改得乱七八糟。后来带我的老工程师看不下去了，丢给我一句话：“别瞎打了，看core dump去。”
从那以后，我才真正学会——崩溃现场，其实藏着所有答案。
8.1 什么是Core Dump？
Core Dump，说白了就是程序崩溃那一刻的内存快照。操作系统把进程的地址空间、寄存器状态、堆栈信息一股脑儿写到磁盘上，生成一个core文件。你拿着这个文件，就能回到崩溃现场，慢慢翻看当时发生了什么。
我习惯把core dump比作“黑匣子”。飞机失事后，调查员靠黑匣子还原事故经过。程序崩溃后，我们就靠core文件还原故障原因。
核心要点：Core Dump = 进程崩溃时的内存快照 + 寄存器状态 + 堆栈信息。
8.2 为什么程序崩溃了却没有Core文件？
很多新手会遇到这个问题：程序明明崩了，但当前目录下啥也没有。嗯，这里要注意，系统默认可能没开core dump，或者限制了core文件的大小。
检查一下这几个地方：
- ulimit -c：查看core文件大小限制。如果显示0，表示禁止生成core文件。
- /proc/sys/kernel/core_pattern：指定core文件的存放路径和命名规则。
- 磁盘空间：空间不足时，core文件写不进去。
我曾经在一个嵌入式项目里排查了一整天，最后发现是ulimit -c被脚本重置成了0。从那以后，我每次调试前第一件事就是敲一遍ulimit -c unlimited。
调试前必做：
ulimit -c unlimited
echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern这样core文件会生成在/tmp目录下，文件名包含程序名和进程ID，方便区分。
8.3 如何分析Core Dump？
拿到core文件后，我们用GDB来解剖它。我个人习惯用这三板斧：
8.3.1 第一板斧：看崩溃位置
gdb ./my_program core.12345
(gdb) bt
#0 0x00007f... in strcpy () from /lib/libc.so.6
#1 0x000055... in process_data (buf=0x7fff...) at main.c:42
#2 0x000055... in main () at main.c:68bt（backtrace）打印函数调用栈。从下往上看，最上面是崩溃时的函数。上面这个例子，崩溃在strcpy里，被process_data调用，而process_data又被main调用。
为什么会崩在strcpy里？大概率是源字符串没以'\0'结尾，或者目标缓冲区太小。说白了，就是缓冲区溢出。
8.3.2 第二板斧：看变量值
(gdb) frame 1
(gdb) info locals
buf = 0x7fff... "Hello World"
len = 128
dest = 0x0切换到第1帧（process_data函数），查看局部变量。看到dest = 0x0了吗？空指针！往空指针里拷贝数据，不崩才怪。
我在项目中遇到过类似情况：一个函数返回了NULL，调用方没检查就直接用了。GDB里一看，变量值是0x0，问题一目了然。
8.3.3 第三板斧：看内存内容
(gdb) x/16xb 0x7fff...
0x7fff...: 0x48 0x65 0x6c 0x6c 0x6f 0x00 0x00 0x00
0x7fff...: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00x命令查看内存。上面这个例子，0x48 0x65 0x6c 0x6c 0x6f就是"Hello"的ASCII码，后面跟着'\0'。嗯，字符串没问题。那问题出在哪？再看dest指向的内存——哦，根本没分配。
警告：不要在生产环境上直接分析core文件。把core文件和对应的可执行文件拷贝到开发机上再分析。生产环境可能缺少调试符号，分析结果不准确。
8.4 常见崩溃场景与分析方法
| 崩溃现象 | 常见原因 | GDB分析命令 |
|---|---|---|
| 段错误（Segmentation Fault） | 空指针、野指针、缓冲区溢出 | bt, info locals, x |
| 非法指令（Illegal Instruction） | 代码段损坏、函数指针错误 | bt, disassemble |
| 栈溢出（Stack Overflow） | 无限递归、局部变量过大 | bt（看调用深度） |
| 断言失败（Assertion Failed） | 逻辑错误、数据不一致 | bt, frame, print |
你想想看，段错误是最常见的。我统计过自己项目里的崩溃，大概70%都是空指针或野指针引起的。剩下的20%是缓冲区溢出，10%是其他原因。
8.5 实战案例：还原一个空指针崩溃
假设我们有这么一段代码：
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void process_data(char *input) {
char buffer[64];
strcpy(buffer, input); // 崩溃在这里
printf("Processed: %s\n", buffer);
}
int main() {
char *data = NULL;
process_data(data);
return 0;
}编译时加上-g选项保留调试信息：
gcc -g -o test test.c
./test
Segmentation fault (core dumped)分析core文件：
gdb ./test core
(gdb) bt
#0 __strcpy_ssse2 () at ../sysdeps/x86_64/multiarch/strcpy.S:164
#1 0x0000000000400566 in process_data (input=0x0) at test.c:7
#2 0x0000000000400580 in main () at test.c:13
(gdb) frame 1
(gdb) info args
input = 0x0
(gdb) print input
$1 = (char *) 0x0看到了吗？input是0x0，空指针。strcpy试图从空指针读取数据，直接触发段错误。
修复方法很简单：调用前检查指针是否为空，或者在process_data函数里加保护判断。
避坑指南：我曾经在一个网络协议栈里遇到类似的崩溃。当时core文件显示崩溃在memcpy里，源地址是0x0。查了半天，发现是某个消息处理函数在异常路径下没有给指针赋值。从那以后，我写代码时养成了一个习惯：所有指针参数，只要可能为NULL，函数入口处就加断言或判空。
8.6 Core Dump分析的知识体系
下面这张图总结了Core Dump分析的核心流程：
这张图展示了从程序崩溃到定位根因的完整链路。核心就三步：先确认环境能生成core文件，然后用GDB三板斧分析，最后定位根因并修复。
8.7 一些实用技巧
- 多线程程序：用
thread apply all bt查看所有线程的调用栈，找出是哪个线程触发了崩溃。 - 优化过的代码：如果编译时开了
-O2或-O3，GDB看到的变量值可能不准。我建议调试时用-O0 -g重新编译一份。 - strip过的程序：生产环境上的程序可能被strip过，没有符号表。这时候core文件里只有地址，没有函数名。解决办法是保留一份带符号表的版本。
- 信号处理：有些程序自己注册了SIGSEGV的信号处理函数，导致core文件生成失败。检查一下
signal(SIGSEGV, handler)这类代码。
注意：Core Dump文件可能包含敏感信息（密码、密钥、用户数据）。分析完后记得及时删除，或者设置合适的文件权限。
好了，Core Dump分析就讲到这里。说白了，它就是一把手术刀，帮你剖开崩溃的瞬间，看清里面的每一处细节。下次程序再崩，别急着加printf了——先看看有没有core文件，然后拿起GDB，慢慢解剖它。