Linux中开启core dump需配置ulimit、sysctl及limits.conf，确保目录权限与磁盘空间；用file/readelf验证core文件，gdb配合bt命令分析调用栈，注意调试符号、动态库路径及容器环境限制。
Linux中进程崩溃时生成core dump文件，是定位程序问题的关键线索。默认很多发行版会禁用或限制core dump，需要手动配置才能获取完整信息。
开启Core Dump功能
系统级设置需修改内核参数和资源限制：
- 检查当前core dump是否启用：
ulimit -c，输出0表示禁用；运行ulimit -c unlimited可临时开启（仅对当前shell有效） - 永久生效：在
/etc/security/limits.conf中添加两行：* soft core unlimited* hard core unlimited
（注意：需重启用户会话或重新登录才生效） - 确认内核允许生成core：
sysctl kernel.core_pattern，常见值如core（当前目录）、/var/core/core.%e.%p（指定路径+命名规则）；修改它可写入/etc/sysctl.conf并执行sysctl -p - 确保目标目录存在、有写权限，且磁盘空间充足（尤其调试大型程序时）
定位与读取Core Dump文件
core文件通常以core或core.xxx命名，可能出现在程序运行目录、home目录，或按kernel.core_pattern指定的路径下：
- 用
file core确认是否为有效ELF格式core文件 - 用
readelf -n core或eu-readelf -n core查看崩溃时的寄存器状态、信号信息 - 若core文件被截断或不完整，可能是磁盘满、权限不足、或
kernel.core_uses_pid=1导致文件名含PID但未注意
用GDB分析Core Dump
核心调试步骤简洁直接：
- 基本命令：
gdb /path/to/executable core（必须使用与崩溃时完全相同的二进制文件，含调试符号） - 进入gdb后，输入
bt（backtrace）查看函数调用栈，这是最常用、最关键的指令 - 用
info registers看CPU寄存器值，x/10i $pc查看崩溃点附近汇编指令 - 若程序依赖动态库，确保
LD_LIBRARY_PATH正确，或在gdb中用set sysroot指定库路径 - 配合
-g编译的可执行文件能显示源码行号；无调试信息时，可用objdump -d反汇编辅助分析
常见问题与规避建议
实际调试中容易卡在几个典型环节：
- “No symbol table”提示：说明二进制未带调试信息，重新用
gcc -g编译，或分离调试符号到.debug文件并配置gdb自动加载 - core文件找不到：检查
kernel.core_pattern是否指向管道（如|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h），此时需用coredumpctl（systemd系统）提取 - 多线程程序崩溃：用
info threads和thread apply all bt查看所有线程栈 - 容器环境默认禁用core dump：需在docker run时加
--ulimit core=-1:-1，并在容器内配置sysctl和limits.conf
