【经典面试】C++ Core Dump该怎么办？

📘 C++ Core Dump 实战排查专栏：从崩溃现场到根因定位

在 C++ 开发中，Core Dump（核心转储）是程序异常终止时操作系统留下的"犯罪现场快照"。它记录了崩溃瞬间的内存状态、寄存器值和调用栈，是定位段错误（Segfault）、非法指令、总线错误等运行时崩溃的最直接证据。本专栏将带你建立一套标准化的 Core Dump 分析与防御体系。

第一章：保全现场 ------ 确保 Core Dump 正确生成

很多开发者遇到崩溃后第一反应是 gdb ./app，却发现没有 core 文件。90% 的排查失败源于环境未配置。

1. 检查并开启 Core Dump

bash 复制代码

# 查看当前限制（0 表示禁用）
ulimit -c

# 临时开启（仅当前 shell 有效）
ulimit -c unlimited

# 永久生效（写入 /etc/security/limits.conf）
echo "* soft core unlimited" >> /etc/security/limits.conf
echo "* hard core unlimited" >> /etc/security/limits.conf

2. 配置 Core 文件命名与路径

默认 core 文件可能生成在启动目录或被 systemd-coredump 接管，导致找不到。建议显式配置：

bash 复制代码

# 查看当前 pattern
cat /proc/sys/kernel/core_pattern

# 推荐配置：包含程序名、PID、时间戳，存放到固定目录
sudo sysctl -w kernel.core_pattern=/tmp/core-%e-%p-%t

⚠️ Docker/K8s 注意 ：容器内 ulimit 受宿主机限制，启动时需加 --ulimit core=-1；若使用 systemd-coredump，需用 coredumpctl list 查找而非直接找文件。

3. 编译选项铁律

必须加 -g：保留调试符号，否则 GDB 只能显示地址无法映射源码。
避免 -O2/-O3 过度优化 ：生产环境可保留 -O2 -g，但排查疑难问题时建议用 -O0 -g 重新编译，防止变量被优化掉、调用栈被内联打平。
不要 strip：发布包可以 strip，但必须保留带符号的原始二进制用于事后分析。

第二章：GDB 分析四步法 ------ 从堆栈到根因

拿到 core 文件后，按以下标准化流程分析：

bash 复制代码

gdb ./your_binary /tmp/core-xxx

Step 1: 确认崩溃信号与位置

gdb 复制代码

(gdb) info signal        # 查看触发崩溃的信号类型
(gdb) bt full            # 完整调用栈 + 每帧局部变量

信号	典型原因	排查方向
`SIGSEGV`	空指针解引用、野指针、数组越界	检查指针有效性、边界条件
`SIGABRT`	assert 失败、double free、heap corruption	查看 abort 前的日志/assert 消息
`SIGBUS`	内存对齐错误、mmap 访问越界	检查结构体打包、共享内存操作
`SIGFPE`	除零、整数溢出	检查除法运算、数值范围
`SIGILL`	非法指令、ABI 不匹配	检查编译器版本、CPU 指令集兼容性

Step 2: 切换栈帧检查上下文

gdb 复制代码

(gdb) frame 3            # 切换到第3帧
(gdb) info locals        # 查看该帧所有局部变量
(gdb) print *ptr         # 解引用查看指针内容
(gdb) list               # 显示崩溃点附近源码

Step 3: 多线程场景必做

gdb 复制代码

(gdb) thread apply all bt    # 打印所有线程调用栈
(gdb) info threads           # 查看线程状态，找到崩溃线程(*)

💡 关键技巧 ：多线程 coredump 中，崩溃线程不一定是问题根源。常见模式是：线程 A 破坏了共享数据，线程 B 读取时崩溃。必须交叉比对多个线程的栈和共享变量状态。

Step 4: 内存与寄存器深度检验

gdb 复制代码

(gdb) x/16xb ptr         # 以十六进制查看 ptr 指向的16字节内存
(gdb) info registers     # 查看寄存器值，验证函数参数传递
(gdb) ptype var          # 查看变量实际类型，确认是否类型混淆

第三章：高频崩溃模式速查表

崩溃现象	GDB 特征	根因	修复方案
空指针解引用	`frame #0` 在 `*ptr = ...`，`print ptr` 为 `0x0`	未判空直接使用	使用前判空；改用智能指针
Use-After-Free	指针非空但值异常；ASan 报 `heap-use-after-free`	对象已释放仍被访问	用 `unique_ptr` 管理生命周期；RAII
栈溢出	`bt` 显示数千层相同函数递归	无限递归或超大栈变量	改迭代；大对象放堆上；增大栈大小
容器越界	`std::vector::operator[]` 崩溃；索引值异常	未检查 size 直接访问	用 `.at()` 替代 `[]`；加边界断言
符号冲突 (ODR)	析构函数崩溃；`nm` 发现同名弱符号	多个翻译单元定义同名类	加 namespace；头文件 guard；`-Wl,--warn-common`
并发数据竞争	崩溃位置随机；变量值不符合预期	未加锁保护共享状态	加 mutex；用原子变量；ThreadSanitizer

第四章：超越 Core Dump ------ 主动防御工具链

Core Dump 是事后验尸 ，高效工程应追求事前预防 + 事中捕获。

1. AddressSanitizer (ASan) ------ 内存问题终结者

bash 复制代码

g++ -fsanitize=address -g -O1 app.cpp -o app
./app

检测：UAF、越界、Double Free、内存泄漏
精度：精确到代码行 + 分配/释放栈
开销：~2x 性能，~3x 内存，测试环境必开

2. ThreadSanitizer (TSan) ------ 并发问题克星

bash 复制代码

g++ -fsanitize=thread -g app.cpp -o app

检测：数据竞争、死锁、锁顺序反转
注意：与 ASan 互斥，不可同时开启

3. UndefinedBehaviorSanitizer (UBSan)

bash 复制代码

g++ -fsanitize=undefined -g app.cpp -o app

检测：整数溢出、空指针成员访问、对齐错误、类型混淆
价值：很多 UB 不会立即崩溃，但埋下定时炸弹

4. 生产环境兜底：Signal Handler + Mini Dump

当 ASan 无法上生产时，注册信号处理器记录最小上下文：

cpp 复制代码

#include <execinfo.h>
void crash_handler(int sig) {
    void* frames[64];
    int n = backtrace(frames, 64);
    backtrace_symbols_fd(frames, n, STDERR_FILENO);
    _exit(128 + sig);  // 保留退出码供监控识别
}
// 在 main() 开头注册
signal(SIGSEGV, crash_handler);
signal(SIGABRT, crash_handler);

第五章：CI/CD 集成最佳实践

将崩溃防御变为自动化门禁：

yaml 复制代码

crash_safety_check:
  stage: test
  script:
    # ASan + UBSan 联合编译
    - cmake -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -g" ..
    - make -j$(nproc)
    # 运行全量测试，任一 sanitizer 报错即失败
    - ctest --output-on-failure
    # 可选：Valgrind 深度检查（耗时较长，夜间构建）
    - valgrind --leak-check=full --error-exitcode=1 ./app
  allow_failure: false

🎯 专栏结语

Core Dump 分析是一项"手艺活"，但不应成为日常救火的依赖。真正的 C++ 高手，不是 gdb 用得最溜的人，而是让程序根本不产生 core dump 的人。将 ASan/TSan 嵌入开发循环、用 RAII 和智能指针消除裸指针、用静态分析拦截 ODR 违规------当这些成为团队肌肉记忆时，Core Dump 将从"每周噩梦"变为"罕见事件"。