开启core dump需设置ulimit -c unlimited并配置limits.conf，通过core_pattern确定文件路径，使用gdb分析调用栈、寄存器及变量，结合-g编译和addr2line定位源码，注意生产环境控制core文件大小。
当Linux程序发生严重错误（如段错误）时，系统可能生成核心转储文件（core dump），记录程序崩溃时的内存、寄存器、调用栈等信息。通过分析这些文件，可以快速定位问题根源，尤其适用于调试C/C++等底层语言编写的程序。
开启Core Dump功能
默认情况下，大多数Linux系统禁用核心转储。要启用它，需检查并设置资源限制：
- 运行 ulimit -c 查看当前core文件大小限制，0表示禁用
- 执行 ulimit -c unlimited 临时开启（仅对当前shell有效）
- 永久生效可编辑 /etc/security/limits.conf，添加：
* soft core unlimited - 确保系统配置允许生成core文件：检查 /proc/sys/kernel/core_pattern
定位Core Dump文件位置
core文件的命名和路径由内核参数 kernel.core_pattern 控制：
- 查看模式：cat /proc/sys/kernel/core_pattern
- 常见输出如：core 或 /var/crash/core.%e.%p.%h.%t
- 可通过echo命令修改，例如：
echo "/tmp/core.%p" > /proc/sys/kernel/core_pattern - 程序崩溃后，在指定路径查找对应core文件
使用GDB分析Core文件
GDB是最常用的core dump分析工具。基本用法如下：
- 启动GDB：gdb
- 例如：gdb ./myapp core.1234
- 进入GDB后，输入 bt（backtrace）查看崩溃时的调用栈
- 使用 frame n 切换到指定栈帧，检查变量值和代码行
- 输入 info registers 查看寄存器状态
- 结合源码编译时加入 -g 选项，可获得更详细的调试信息
辅助工具与技巧
除GDB外，还可借助其他手段提升分析效率：
- 使用 file core 确认core文件有效性及关联的可执行文件
- 通过 gdb --batch --quiet -ex "bt" -ex "quit"
- 若程序依赖共享库，确保GDB能正确加载（可用 info sharedlibrary 检查）
- 对于多线程程序，使用 thread apply all bt 查看所有线程的调用栈
- 结合 addr2line 工具将地址转换为源码行号
基本上就这些。只要开启core dump、保留符号信息，并熟练使用GDB，就能高效排查多数崩溃问题。注意生产环境建议限制core文件大小或关闭该功能，避免磁盘耗尽。
