开启core dump需执行ulimit -c unlimited并设置core_pattern，编译时加-g生成调试信息，程序崩溃后用gdb ./exe core加载core文件，通过bt命令查看调用栈，定位如空指针等崩溃原因。
在C++开发中，程序崩溃时生成的core dump文件对定位问题非常关键。它记录了程序崩溃时的内存状态、调用栈和寄存器信息，是调试段错误（Segmentation Fault）等问题的重要工具。
开启core dump生成
默认情况下，Linux系统可能禁用了core dump功能。需要手动开启：
1. 检查当前限制：ulimit -c
如果返回0，表示core dump被禁用。
2. 启用core dump：
ulimit -c unlimited
这会允许生成无大小限制的core文件。该设置只对当前shell有效。
3. 设置core文件命名格式（可选）：
echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern
%e 表示程序名，%p 表示进程ID。这样core文件会保存到/tmp目录下，便于管理。
触发并生成core dump
编写一个会崩溃的C++程序测试：
#include编译：int main() { int* p = nullptr; *p = 10; // 触发段错误 return 0; }
g++ -g -o test test.cpp
运行：
./test
程序崩溃后，会在当前目录或指定路径生成core文件（如core.1234）。
使用GDB分析core dump
用GDB加载程序和core文件进行分析：
立即学习“C++免费学习笔记（深入）”；
gdb ./test core
进入GDB后，常用命令有：
- bt：查看完整的调用栈，定位崩溃位置
- frame N：切换到指定栈帧
- print 变量名：查看变量值
- info registers：查看寄存器状态
- list：显示源码上下文
例如，执行bt后可能看到：
#0 0x00000000004010b6 in main () at test.cpp:5明确指出空指针解引用发生在main函数第5行。
注意事项
确保编译时加上-g选项，保留调试信息，否则GDB无法显示源码和变量名。
生产环境中core文件可能很大，需合理设置存储路径和磁盘空间。
多线程程序的core dump同样可用GDB分析，配合thread apply all bt可查看所有线程栈。
基本上就这些。开启core dump + GDB分析，是C++排查运行时崩溃最直接有效的方法。
