首先开启core dump功能，通过ulimit -c unlimited临时启用并修改/etc/security/limits.conf永久生效；接着配置kernel.core_pattern指定core文件路径与命名规则，确保目标目录可写；程序崩溃后使用gdb 加载core文件，执行bt查看调用栈、info registers检查寄存器状态、frame切换栈帧并print变量值以定位问题；需确保二进制文件含调试信息（编译加-g选项），排查磁盘空间、信号处理、多线程退出及容器环境限制等问题，结合dmesg日志确认崩溃详情。
当Linux进程异常崩溃时，调试的关键在于获取并分析程序崩溃时的内存状态。最有效的手段之一就是通过core dump文件进行事后调试。下面介绍如何开启core文件生成、定位问题进程，并使用工具如gdb进行深入分析。
开启Core Dump功能
默认情况下，许多系统会禁用core文件生成。需要手动启用：
- 使用ulimit -c查看当前限制，0表示禁用
- 运行ulimit -c unlimited临时开启
- 若需永久生效，修改/etc/security/limits.conf，添加：
* soft core unlimited - 确保系统sysctl配置允许core dump：
kernel.core_pattern=/tmp/core.%e.%p.%h.%t
可通过/proc/sys/kernel/core_pattern查看或修改
确认Core文件生成路径与命名规则
core文件是否生成取决于core_pattern设置。常见格式包含程序名、PID、主机名、时间戳等：
- %e：可执行文件名
- %p：进程PID
- %h：主机名
- %t：时间戳（Unix时间）
例如设置为/var/crash/core.%e.%p后，程序崩溃会在指定目录生成对应文件。注意目标目录需有写权限。
使用GDB分析Core文件
拿到core文件后，结合原程序二进制文件进行调试：
- 命令格式：gdb
- 启动后输入bt（backtrace）查看调用栈，定位崩溃位置
- 使用info registers查看寄存器状态
- 用frame N切换到指定栈帧，再用print 检查变量值
- 若符号信息缺失，需确保编译时加-g选项生成调试信息
常见问题与排查技巧
即使配置正确，也可能看不到core文件，常见原因包括：
- 磁盘空间不足或路径无写权限
- 程序设置了自定义信号处理（如SIGSEGV被捕获）
- 多线程程序中主线程未等待子线程退出导致提前终止
- 容器环境或systemd服务默认禁用core dump
- 静态链接或strip过的二进制文件无法提供有效符号信息
建议在测试环境中复现问题，并配合dmesg | grep -i segfault查看内核日志，确认崩溃类型和进程PID。
基本上就这些。只要能生成core文件，再配合正确的二进制和调试符号，大多数段错误、空指针、栈溢出等问题都能快速定位。关键是提前规划好日志和dump存储策略，避免事发时无据可查。
