★ FEATURED ARTICLE 1. 为什么core文件是排查崩溃的“黑匣子”程序跑着跑着突然没了终端只留下一句“Segmentation fault (core dumped)”然后一切归于平静。这种场景但凡写过几年C/C的人都不陌生。很多人第一反应是加打印、加日志然后重新跑一遍运气好能复现运气不好折腾一整天也抓不到现场。而core文件就是操作系统在进程崩溃瞬间留下的“现场快照”它把进程当时的内存镜像、寄存器状态、调用栈、堆栈数据全部冻结成一个文件供你事后慢慢解剖。我第一次真正体会到core文件的价值是在处理一个多线程服务的偶发崩溃时。那个bug平均两天出现一次日志里什么都看不出来加了多少打印都无济于事。后来开启了core dump拿到core文件后用调试器一分析发现是一个后台线程在对象析构后仍然访问了成员变量调用栈清清楚楚地指向了那一行代码。从拿到core到定位问题前后不到二十分钟。如果靠日志去猜可能一周都找不到根因。这篇文章面向的是所有需要和底层程序打交道的开发者——不管你是写C/C的后端工程师还是做嵌入式开发的嵌入式软件工程师或者是对系统行为感兴趣的技术爱好者。我会从core文件的生成机制讲起一步步拆解怎么开启、怎么查看、怎么调试把我在实际工作中踩过的坑和总结的技巧都摊开来讲。核心关键词就三个core文件生成、调试器分析、崩溃定位。读完你至少能做到拿到一个core文件知道从哪里下手能独立分析出崩溃原因。2. core文件是怎么产生的从信号到磁盘的完整链路2.1 进程崩溃时操作系统做了什么当一个进程触发了某些致命信号操作系统内核会执行一套默认动作。以最常见的SIGSEGV段错误为例内核检测到非法内存访问后会向进程发送SIGSEGV信号。如果进程没有注册自定义的信号处理函数来捕获它内核就会执行默认行为——终止进程并根据配置决定是否生成core文件。这个core文件本质上是一个ELF格式的文件里面包含了进程在崩溃时刻的完整内存布局代码段、数据段、堆、栈、共享库的映射信息以及所有线程的寄存器状态。你可以把它理解成给进程拍了一张“全身CT”每个内存地址上有什么数据、CPU执行到了哪条指令、各个线程分别卡在哪里全部记录在案。注意core文件的大小通常和进程占用的内存成正比一个占用2GB内存的进程core文件可能也有1-2GB。磁盘空间不够的话生成过程会失败这一点后面会详细说。2.2 哪些信号会触发core dump不是所有信号都会产生core文件。下面这张表列出了常见的会触发core dump的信号及其含义信号名称信号值触发原因典型场景SIGSEGV11非法内存访问空指针解引用、数组越界、访问已释放内存SIGABRT6进程主动中止assert失败、C异常未捕获、堆损坏检测SIGBUS7总线错误内存对齐问题、映射文件访问越界SIGFPE8算术异常整数除零、浮点溢出SIGILL4非法指令代码段损坏、跳转到非法地址SIGQUIT3终端退出信号键盘输入Ctrl\触发SIGTRAP5断点陷阱调试器断点、int3指令SIGKILL信号值9和SIGTERM信号值15是不会触发core dump的因为SIGKILL是强制杀死进程没有任何机会做任何事SIGTERM虽然可以被捕获但默认行为是干净退出不产生core。2.3 core文件的命名规则与存放位置core文件的默认名称和存放路径由内核参数kernel.core_pattern决定。在大多数Linux发行版上默认值可能是core或者core.%p其中%p会被替换成进程PID。你可以通过下面的命令查看当前设置cat /proc/sys/kernel/core_pattern常见的几种配置格式core在当前工作目录生成名为core的文件core.%p在当前工作目录生成core.PID格式的文件/tmp/core.%e.%p.%t在/tmp目录下生成包含可执行文件名、PID和时间戳|/usr/bin/systemd-coredump通过管道交给systemd-coredump处理现代发行版常见如果你的系统配置的是管道方式以|开头core文件不会直接写到磁盘上而是交给对应的程序处理。比如systemd-coredump会把core文件存到/var/lib/systemd/coredump/目录下需要用coredumpctl命令来查看和管理。3. 开启core dump从ulimit到内核参数的完整配置3.1 用ulimit解除core文件大小限制即使内核配置了生成core文件如果进程的core文件大小限制core file size limit设置为0core文件也不会被创建。这是很多人遇到的第一个坑——明明配置了core_pattern崩溃后却找不到core文件。查看当前限制ulimit -c如果输出是0说明core文件被禁用了。临时开启只对当前shell会话有效ulimit -c unlimited如果想设置一个上限而不是无限制可以指定具体数值单位是块通常一块是512字节或1KB取决于系统ulimit -c 2097152 # 大约1GB到2GB具体取决于块大小实操心得ulimit -c unlimited只在当前shell及其子进程中生效。如果你在终端A设置了然后在终端B启动程序终端B的进程不受影响。所以要么在启动程序的同一个shell里设置要么把配置写进启动脚本。3.2 永久生效的配置方法临时设置每次都要手动敲一遍容易忘。要让配置永久生效需要修改系统配置文件。在/etc/security/limits.conf中添加* soft core unlimited * hard core unlimited第一列是用户或用户组*表示所有用户第二列是软限制还是硬限制第三列是限制类型第四列是值。软限制是实际生效的值硬限制是软限制的上限普通用户可以把软限制调到硬限制以内但不能超过硬限制。修改后需要重新登录才生效。另外某些系统上systemd会覆盖limits.conf的设置可能还需要检查/etc/systemd/system.conf中的DefaultLimitCORE配置。3.3 内核参数core_pattern的精细控制core_pattern决定了core文件的名字和存放位置。通过sysctl命令可以动态修改# 临时修改重启后失效 sysctl -w kernel.core_pattern/tmp/core.%e.%p.%t # 永久修改写入配置文件 echo kernel.core_pattern/tmp/core.%e.%p.%t /etc/sysctl.conf sysctl -pcore_pattern支持多种占位符常用的有占位符含义示例%p进程PID12345%e可执行文件名myapp%t崩溃时间戳Unix时间1700000000%h主机名server01%u用户ID1000%g组ID1000%s触发core的信号编号11%ccore文件大小软限制unlimited一个比较实用的配置是/var/coredump/core.%e.%p.%t把所有core文件集中存放避免散落在各个工作目录里。记得提前创建目录并确保进程有写入权限。注意如果core_pattern以|开头表示通过管道把core文件交给指定程序处理。这种情况下ulimit的限制可能不生效因为core文件不直接写磁盘。你需要查看对应程序的配置来确定core文件存到了哪里。3.4 容器环境下的特殊处理在容器里跑程序时core dump的配置会更复杂一些。容器默认可能不允许生成core文件需要几个额外步骤首先容器启动时需要添加--ulimit coreunlimited参数以Docker为例。其次core_pattern是宿主机内核参数容器内修改可能不生效或者影响宿主机。比较稳妥的做法是在宿主机上配置好core_pattern把core文件输出到容器可访问的卷中或者使用|管道方式配合容器内的处理程序。另外容器内的进程PID和宿主机上的PID不一样core文件命名中的%p是宿主机视角的PID排查时需要注意对应关系。4. 用调试器打开core文件从加载到调用栈分析4.1 准备工作可执行文件与调试符号拿到core文件后第一件事是找到对应的可执行文件。调试器需要可执行文件来解析core文件中的内存布局和符号信息。如果程序在崩溃后被重新编译过或者可执行文件被替换了core文件可能无法正确解析。# 基本用法 gdb /path/to/executable /path/to/corefile # 如果可执行文件带调试符号直接就能看到函数名和行号 # 如果可执行文件被strip过需要单独加载调试符号文件 gdb -ex symbol-file /path/to/debug/symbols /path/to/executable /path/to/corefile编译程序时建议加上-g选项保留调试信息同时用-O0或-Og降低优化级别。高优化级别如-O2、-O3会导致编译器重排指令、内联函数、优化掉变量调试时看到的行号和变量值可能和源码对不上增加分析难度。实操心得生产环境通常会用-O2编译以追求性能但可以同时保留一份带-g的未优化版本用于调试。或者使用-g配合-O2虽然变量可能被优化但至少函数名和行号信息是完整的。另外可以用objcopy --only-keep-debug把调试信息单独提取出来部署时只带可执行文件调试时再加载符号文件。4.2 加载core文件后的第一手信息进入gdb后最先要看的几个信息# 查看程序崩溃时的信号和地址 (gdb) bt # 输出示例 # Program terminated with signal SIGSEGV, Segmentation fault. # #0 0x00005555555551a9 in crash_function () at test.c:5 # 5 *ptr 42; # 查看所有线程的调用栈 (gdb) thread apply all bt # 查看寄存器状态 (gdb) info registers # 查看崩溃点附近的汇编指令 (gdb) disassemble /sbtbacktrace命令是最核心的它展示了崩溃时的函数调用链。从最内层的#0帧开始逐层向外。每一帧包含函数名、参数、源文件和行号如果有调试信息的话。如果bt输出中大量出现??说明对应的库没有调试符号。这时候可以安装对应库的调试符号包或者在gdb中手动指定符号搜索路径(gdb) set debug-file-directory /usr/lib/debug (gdb) set solib-search-path /path/to/libs4.3 切换栈帧与查看变量调用栈的每一帧都有编号用frame命令可以切换(gdb) frame 2 # 切换到第2帧 (gdb) info locals # 查看当前帧的局部变量 (gdb) info args # 查看当前帧的函数参数 (gdb) print variable_name # 打印指定变量的值 (gdb) print *pointer # 打印指针指向的内容 (gdb) print array[0]10 # 打印数组的前10个元素查看变量时经常会遇到“optimized out”的提示这是因为编译器优化把变量优化掉了。这时候可以尝试查看寄存器或者反汇编当前函数从汇编层面推断变量的值。4.4 多线程崩溃的分析方法多线程程序的core文件分析要复杂一些因为崩溃的线程不一定是罪魁祸首。一个线程崩溃了但根因可能是另一个线程写坏了内存。# 查看所有线程 (gdb) info threads # 切换到指定线程 (gdb) thread 3 # 查看该线程的调用栈 (gdb) bt # 查看所有线程的调用栈最常用 (gdb) thread apply all bt fullthread apply all bt full会打印所有线程的完整调用栈和局部变量输出可能很长但信息量最大。分析时重点关注哪些线程持有锁、哪些线程在等待、崩溃线程访问的内存是否被其他线程修改过。实操心得多线程崩溃中有一类很隐蔽的情况是“堆内存被写坏”。崩溃点可能在malloc或free内部但真正的问题在于之前某处发生了缓冲区溢出。这时候可以尝试用AddressSanitizer重新编译运行来复现或者在gdb中检查堆的完整性。另外thread apply all bt的输出建议重定向到文件里慢慢看终端里翻页容易漏掉关键信息。5. 常见崩溃场景的core文件分析实战5.1 空指针解引用最经典也最容易定位空指针崩溃的core文件分析起来最直接。bt命令会直接指向出问题的行print一下指针变量就能确认是NULL。// 示例代码 void process_data(struct Data *data) { >(gdb) bt # #0 process_data (data0x0) at example.c:3 (gdb) frame 0 (gdb) print data # $1 (struct Data *) 0x0确认是空指针后往上一层帧看调用者为什么传了NULL进来。是初始化遗漏、错误处理分支没返回、还是某个函数返回了NULL但没检查。5.2 堆内存破坏崩溃点不等于问题点堆内存被写坏是最难查的一类问题。典型表现是程序在malloc或free内部崩溃但调用栈显示的是无辜的内存分配代码。(gdb) bt # #0 __libc_malloc () # #1 create_object () at object.c:45 # #2 main () at main.c:20崩溃在__libc_malloc里但问题很可能是之前某处写越界破坏了堆的元数据。这时候需要检查崩溃点之前的所有内存写操作用x命令查看堆内存区域看是否有明显的异常数据考虑用AddressSanitizer或Valgrind重新运行来定位# 查看堆内存区域 (gdb) info proc mappings # 找到[heap]段的地址范围 (gdb) x/100x 0x5555555590005.3 栈溢出递归失控的典型表现栈溢出导致的崩溃core文件里会看到非常深的调用栈通常是同一个函数反复出现。(gdb) bt # #0 recursive_func (n100000) at recursion.c:5 # #1 recursive_func (n99999) at recursion.c:5 # #2 recursive_func (n99998) at recursion.c:5 # ... 重复几千行 ...gdb默认会限制backtrace的显示层数可以用set backtrace limit调整(gdb) set backtrace limit 100000 (gdb) bt或者直接看栈顶的几帧确认是递归失控后检查递归的终止条件为什么没有生效。5.4 多线程死锁core文件里的“静止画面”死锁本身不会导致崩溃但如果程序因为死锁被外部信号杀死比如超时后被SIGABRTcore文件就能帮我们看清死锁现场。(gdb) thread apply all bt # Thread 1: # #0 __lll_lock_wait () # #1 pthread_mutex_lock () # #2 thread_a_func () at deadlock.c:10 # Thread 2: # #0 __lll_lock_wait () # #1 pthread_mutex_lock () # #2 thread_b_func () at deadlock.c:20两个线程都卡在pthread_mutex_lock上说明它们在互相等待对方持有的锁。查看deadlock.c:10和deadlock.c:20分别请求的是哪把锁就能还原出死锁的环路。6. 高频问题排查与避坑指南6.1 core文件不生成按这个顺序排查排查步骤检查命令可能的问题1. 检查ulimitulimit -c输出为0core被禁用2. 检查core_patterncat /proc/sys/kernel/core_pattern配置为3. 检查磁盘空间df -h磁盘满core写入失败4. 检查目录权限ls -ld /tmp进程无权限写入core文件目录5. 检查进程限制cat /proc/PID/limits进程自身的core限制为06. 检查容器配置docker inspect容器未开启core dump权限6.2 调试符号缺失怎么办如果bt输出全是??说明缺少调试符号。解决方法编译时加-g选项安装系统库的调试符号包如libc6-dbg用set debug-file-directory指定符号搜索路径用file命令确认可执行文件是否被strip过file /path/to/executable # 输出中包含 not stripped 表示有符号 # 输出中包含 stripped 表示符号被移除6.3 core文件太大导致生成失败大内存进程的core文件可能达到几个GB如果磁盘空间不足或者ulimit设置太小core文件会生成失败。几个应对策略设置core_pattern时用%c占位符但注意%c是限制值不是实际大小用coredump_filter控制哪些内存段被dump比如排除文件映射的只读段考虑用gcore命令在进程运行时主动生成core文件可以控制生成时机# 查看当前coredump_filter cat /proc/self/coredump_filter # 设置只dump匿名私有内存和栈 echo 0x33 /proc/PID/coredump_filter6.4 分析core文件时的常见误区误区一只看崩溃点。崩溃点往往只是问题的表现形式不是根因。空指针崩溃的根因可能是上游函数返回了NULL没检查堆破坏的根因可能是更早的越界写。误区二忽略线程间的交互。单线程思维分析多线程core文件很容易漏掉关键线索。一定要用thread apply all bt看全貌。误区三过度依赖调试符号。没有符号的时候反汇编和寄存器分析同样能提供大量信息。学会看汇编是进阶的必经之路。误区四不保存现场。core文件分析过程中可能会修改内存、切换帧建议先把关键信息导出到文件避免反复加载。实操心得我习惯在gdb里用set logging on开启日志记录把整个分析过程保存下来。这样即使core文件被清理了分析记录还在方便后续复盘。另外bt full的输出建议重定向到文件用文本工具慢慢分析比在gdb里翻页高效得多。6.5 生产环境core文件管理建议生产环境不能无限制地生成core文件否则磁盘很快会被撑爆。几个实用建议用core_pattern把core文件集中到独立分区设置分区配额用%e.%p.%t命名方便按程序名和时间筛选写一个清理脚本定期删除超过N天的core文件对核心服务开启core dump对非核心服务关闭考虑用systemd-coredump统一管理它自带大小限制和轮转策略# 查看systemd-coredump管理的core文件 coredumpctl list # 查看指定程序的core文件 coredumpctl list /path/to/executable # 用gdb调试最近的core文件 coredumpctl gdb # 导出core文件 coredumpctl dump -o /tmp/core.dump7. 进阶技巧让core文件分析更高效7.1 用gdb脚本自动化常用分析步骤每次分析core文件都要敲一遍相同的命令效率很低。可以把常用命令写进gdb脚本# analyze.gdb set pagination off set logging file /tmp/core_analysis.log set logging on echo \n Backtrace \n bt echo \n All Threads \n thread apply all bt echo \n Registers \n info registers echo \n Mappings \n info proc mappings set logging off quit使用方式gdb -x analyze.gdb /path/to/executable /path/to/corefile7.2 结合反汇编定位无符号崩溃没有调试符号时反汇编是主要手段。关键是找到崩溃时PC寄存器指向的地址然后反汇编该地址附近的指令(gdb) info registers rip # rip 0x5555555551a9 (gdb) x/10i 0x5555555551a9-20 # 反汇编崩溃点前后的指令 (gdb) disassemble /r 0x5555555551a9, 0x5555555551c9通过分析汇编指令可以推断出崩溃时在执行什么操作是在读内存、写内存、还是调用函数。结合寄存器的值能还原出当时的执行状态。7.3 用core文件做回归验证修复bug后可以用原来的core文件验证修复是否有效。方法是在gdb中加载修复后的可执行文件和原core文件看崩溃点是否还能复现。虽然core文件记录的是旧版本的内存状态但如果修复涉及的是逻辑问题而非内存布局变化这种方法仍然有参考价值。另外可以把core文件中的关键内存数据导出作为单元测试的输入确保修复后的代码能正确处理导致崩溃的输入数据。# 导出内存区域到文件 (gdb) dump memory /tmp/heap_dump.bin 0x555555559000 0x55555555a0007.4 跨平台core文件分析注意事项不同操作系统和架构的core文件格式不同分析时需要注意Linux的core文件是ELF格式用gdb分析macOS的core文件也是Mach-O格式用lldb分析Windows的minidump用WinDbg或Visual Studio分析嵌入式平台可能使用特殊的core格式需要对应的工具链跨平台分析时可执行文件、调试符号和core文件必须来自同一平台和架构否则无法正确解析。如果需要在不同架构间分析可以考虑用QEMU等模拟器加载对应架构的gdb。8. 个人实操体会与建议core文件分析这项技能看再多教程都不如亲手分析几个真实崩溃来得有效。我刚开始接触的时候面对一个几百MB的core文件完全不知道从哪下手bt输出一堆??就卡住了。后来逼着自己一个个查、一个个试慢慢就摸出了门道。几个我觉得最值得养成的习惯第一程序编译时永远带上-g哪怕生产环境用-O2也保留一份带符号的版本第二core文件生成后第一时间用file命令确认格式和架构避免拿错文件白忙活第三分析时先看全局再看局部thread apply all bt永远比单看崩溃线程信息量大第四把每次分析的步骤和结论记录下来下次遇到类似问题能快速对照。还有一个容易被忽视的点core文件分析只是手段真正的目标是修复问题。有时候花大量时间分析core文件最后发现是一个很简单的逻辑错误。所以分析到一定程度如果已经能推断出根因就果断去改代码验证不要陷入“一定要把每个寄存器都搞清楚”的执念里。效率优先够用就好。最后分享一个我常用的组合命令拿到core文件后先跑这一套基本能覆盖80%的排查场景gdb -batch \ -ex set pagination off \ -ex bt \ -ex thread apply all bt \ -ex info registers \ -ex info proc mappings \ /path/to/executable /path/to/corefile 21 | tee /tmp/core_report.txt输出保存到文件后用grep搜索关键函数名、用less慢慢翻比在gdb交互界面里操作要顺手得多。这套流程我在多个项目里反复用过从嵌入式设备到大型服务端程序基本都能快速定位到问题方向。
阅读完成 · 觉得有帮助？
