简单来说，Core Dump 就是程序崩溃时，操作系统帮你 “冻结” 的一份 “现场快照”，里面记录了程序崩溃瞬间的内存数据、函数调用栈、寄存器状态等关键信息。只要掌握了它，你不用再靠 “猜” 和 “试” 排查问题，就能精准定位到代码里的 bug。接下来内容不会讲复杂的底层原理，而是聚焦实用技能：从怎么配置才能让程序生成 Core Dump 文件，到用 GDB 快速分析快照找到崩溃原因，再到避开那些导致 Core Dump 生成失败的坑。无论你是刚接触 Linux 开发的新手，还是常跟线 ...-Go服务器开发

以下是关于 Core Dump 的实用补充内容，涵盖配置、分析和常见问题解决：

一、如何配置生成 Core Dump

解除系统限制
- 检查当前限制：ulimit -c
  - 若显示 0，则需设置为无限制：
```
ulimit -c unlimited  # 临时生效
```
- 永久生效：
  在 /etc/security/limits.conf 末尾添加： “`
  - soft core unlimited
  ”`
设置 Core Dump 存储路径
- 默认存储在程序运行目录，可通过以下方式自定义：
```
# 统一路径示例
echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
```
  参数说明：
  - %e：程序文件名
  - %p：进程 PID
  - %t：崩溃时间戳

二、用 GDB 快速分析 Core Dump

基础命令

gdb <程序路径> <core文件路径>

示例：

gdb /home/user/myapp /tmp/core-myapp-12345-1627890123

定位崩溃点

输入 bt（backtrace）查看崩溃时的调用栈：


(gdb) bt
#0  0x00007f8a5b1a2345 in raise () from /lib64/libc.so.6
#1  0x00007f8a5b18e8d5 in abort () from /lib64/libc.so.6
#2  0x000055d4c3f40123 in main () at example.c:10

直接锁定问题代码行（如 example.c:10）

查看变量状态
- print <变量名>：检查崩溃时变量的值
- info registers：查看寄存器状态

三、常见坑与解决方案

Core Dump 文件未生成
- 确认 ulimit -c 不为 0
- 检查磁盘空间是否充足
- 程序是否被 chmod +s 提权？部分系统限制 setuid 程序生成 core
Segmentation Fault 无 core 文件？
- 可能是程序捕获了信号（如 SIGSEGV），需确保信号未被忽略
Core 文件过大
- 压缩存储：配置 core_pattern 时通过管道调用压缩工具
```
echo "|/usr/bin/gzip > /tmp/core-%e-%p-%t.gz" > /proc/sys/kernel/core_pattern
```

四、实战技巧

脚本化分析：将常用 GDB 命令写入脚本（如 analysis.gdb）：
```
set pagination off
bt full
info registers
quit
```
执行：gdb -x analysis.gdb myapp corefile
自动化排查：结合 addr2line 快速转换地址为代码行： “`bash addr2line -e myapp <崩溃地址>

内容由零声教学AI助手提供，问题来源于学员提问