coredump从信号到GDB还原：Linux核心转储全流程实战解析

在上一篇聊coredump时我把触发条件、几个系统开关和一个简单的崩溃用例过了一遍。当时有人说这些东西纸上谈兵都会可真到自己线上服务崩了按步骤折腾半天还是没看到core文件。这篇我就把这个问题当引子把实验做完整顺便把coredump从信号产生、内核转储、落盘再到gdb还原崩溃现场的整条链路拆开讲透。内容全部基于我在x86_64 Linux环境下的实际操作命令和代码都可以直接抄。1. coredump基础回顾与实验环境准备1.1 先搞明白coredump到底在干嘛coredump也叫核心转储Core Dump是操作系统在进程异常终止时把进程地址空间的内存内容、寄存器状态、打开的文件描述符、信号处理信息等一并保存下来的文件。你可以把它理解成事故发生瞬间的完整快照不管是空指针解引用、栈溢出、堆越界还是某个第三方库抛出的SIGABRT只要进程真的崩了快照里就会留下痕迹。我见过不少同事一开始对coredump有误解以为它就是一堆乱码二进制不用也罢。其实恰恰相反这份“乱码”里包含的信息比线上日志里那几行Error要丰富得多。日志只能告诉你“哪里报错了”coredump能告诉你“当时栈长什么样、变量值是多少、参数传成了什么、哪个库的哪一行触发了崩溃”。很多反复出现的疑难崩溃最终都是靠core文件里的寄存器值锁定的。这就像飞机失事后的黑匣子日志是驾驶舱通话记录coredump就是飞行数据记录仪。黑匣子没人会嫌它占地方coredump同理。这也是为什么生产环境强烈建议保留core文件而不是一出事就重启了事。1.2 实验环境与前置条件我的实验环境是一台x86_64的Linux机器内核5.x用户态工具用的是GCC和GDB版本不影响命令通用性。做实验前需要准备好三样东西一个会崩溃的测试程序或者从线上拿到的崩溃现场。GDB至少8.x以上新版本对调试信息和压缩core的支持更好。root权限或者一个能修改/proc/sys/kernel/下内核参数的账号。虽然生成core文件本身不需要root但设置全局的core_pattern往往需要权限。建议把实验放在独立目录里比如/tmp/coredump-lab不要直接塞在项目根目录避免把一堆core文件提交到版本管理里。编译时一定要带-g选项。这是最容易忽略又最关键的一步。-g会往程序里写入调试符号GDB才能把二进制里的地址映射回源码行号。没有符号的core文件也不是完全没用但定位难度会翻好几倍后面我会专门讲这个问题。1.3 内核参数与ulimit配置见过太多人在shell里敲一个ulimit -c unlimited以为就万事大吉了结果程序还是没产出core文件。这里需要分清三个层面的配置第一层ulimit限制。ulimit -c决定当前shell进程及其子进程允许生成的core文件大小上限。设置为0表示禁止产生coreunlimited表示不限制。它可以用ulimit -c unlimited临时修改也可以写在shell配置里永久生效。第二层内核的core_pattern规则。cat /proc/sys/kernel/core_pattern告诉你去哪里找core文件。不同发行版差别很大有的默认直接写当前工作目录下的core文件有的则配置成管道交给systemd-coredump。这块是很多人找不到core文件的主要根源。第三层dumpable属性。fs.suid_dumpable以及进程调用prctl(PR_SET_DUMPABLE)会影响特权进程或做了安全设置的程序能否被转储。服务器上常见的加固措施会把它设成0于是即使ulimit和core_pattern都对setuid程序依然不产生core。所以正确的配置文件顺序应该是# 1. 查看当前限制 ulimit -c # 2. 放开限制 ulimit -c unlimited # 3. 定义core文件输出位置和格式 sysctl -w kernel.core_pattern/tmp/coredump-lab/core_%e_%p_%t # 4. 确认生效 cat /proc/sys/kernel/core_pattern%e表示可执行文件名%p表示PID%t表示崩溃时间戳。这几个占位符对后续排查非常有用尤其%p同一程序频繁崩溃时PID是区分不同core文件的关键ID。2. 核心转储机制原理拆解2.1 从进程崩溃到落盘的完整链路很多人只知道“崩了就会产生core”但不知道这个过程中内核到底做了哪些事。我尽量用大白话讲一遍第一步异常触发。CPU在指令执行过程中遇到非法内存访问比如解引用了NULL指针MMU触发缺页异常异常处理机制把这个条件映射成SIGSEGV信号投递给进程。这里不区分是真正摸到了非法地址还是线程栈太小溢出到保护区内核都会走同一套信号分发流程。第二步信号处置判断。进程可以通过sigaction注册信号处理函数。如果进程捕获了SIGSEGV内核会把控制权交给处理函数进程可能自己恢复也可能选择_exit。只有在进程没有捕获、或者处理函数再次触发同样信号的时候内核才执行信号的默认动作。SIGSEGV、SIGABRT、SIGBUS、SIGILL这些信号的默认动作之一就是“终止进程并生成core dump”。第三步内核调用do_coredump相关逻辑。它需要检查进程的RLIMIT_CORE是否允许转储然后找到core_pattern指定的位置可能是普通文件也可能是管道。如果是文件就直接把进程的内存段写出去如果是管道会启动那个处理程序比如systemd-coredump由它负责接收数据、压缩存储。第四步写完后进程彻底退出。如果转储失败比如磁盘满了、目录不可写进程照样终止但core文件不会留下这也就解释了“程序确实崩了但没core”的另一半原因。2.2 转储文件格式与ELF结构很多人以为core文件是一种独特的私有格式其实它依然是ELF格式只是类型是CORE。用file core看一眼就能确认$ file core_crash_1234_1699000000 core_crash_1234_1699000000: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style既然是ELF就能用readelf来查看内部结构。比如readelf -n core可以看到崩溃时保存的寄存器状态和信号信息$ readelf -n core_crash_1234_1699000000 Notes at offset 0x... Owner Data size Description CORE 0x... NT_PRSTATUS (prstatus structure) CORE 0x... NT_PRPSINFO (prpsinfo structure) CORE 0x... NT_SIGINFO (siginfo_t data)这些note段是GDB分析的关键。NT_PRSTATUS里保存了每个线程的寄存器快照NT_SIGINFO里保存了触发的信号编号GDB拿到这些数据就能结合程序头表里的内存段描述重建出进程崩溃瞬间的调用栈和变量状态。用readelf -h core还能看到program headers里面记录了哪些内存段被保留、它们原本的加载地址是什么。这些信息对分析共享库基址偏移特别有用后文实战里会用到。2.3 为什么有时候看不到core文件这是一个非常现实的问题。按我的经验找不到core文件时先用下面这个顺序排查80%的情况都能定位看core_pattern有没有指向管道。如果输出类似|/usr/lib/systemd/systemd-coredump %P那默认就不会在当前目录生成core文件而是被systemd接管了。需要用coredumpctl list来找。看ulimit是否被限制。进入启动崩溃程序的shell里执行ulimit -c返回0就说明被禁了。看目录权限和磁盘空间。设置core_pattern到/tmp/cores后如果该目录不存在或者当前用户没有写权限内核会静默失败不会主动提示。看fs.suid_dumpable。sysctl fs.suid_dumpable返回0表示setuid类程序不允许转储。如果你排查的是root启动的服务也可能受这个影响。看程序里有没有自己设置PR_SET_DUMPABLE。比如有些C语言程序启动时调用了prctl(PR_SET_DUMPABLE, 0)来禁止自身被转储这种属于主动屏蔽只能改代码。我遇到过最典型的情况是core_pattern明明是文件路径程序也显示“段错误 (core dumped)”结果ls一看还是什么都没有。最后发现是因为shell里开了bash的ulimit -c 0而启动程序的脚本又没继承新设置。这种配置类问题比内核逻辑难缠多了。3. 实验设计与操作实录3.1 实验一制造一次段错误并捕获core我建立了一个模拟项目X用它来演示完整的崩溃捕获流程。先写一个最简单的崩溃程序#include stdio.h void trigger_crash(void) { int *p NULL; *p 1; } int main(void) { printf(before crash\n); trigger_crash(); return 0; }编译并运行gcc -g -o crash crash.c mkdir -p /tmp/coredump-lab/cores sysctl -w kernel.core_pattern/tmp/coredump-lab/cores/core_%e_%p_%t ulimit -c unlimited ./crash运行输出before crash Segmentation fault (core dumped)注意观察输出里的(core dumped)字样它说明内核确实生成了core文件。去目标目录看一眼$ ls -lh /tmp/coredump-lab/cores/ -rw------- 1 dev dev 376K Jan 15 10:21 core_crash_5678_1699000000到这里第一只实验就完成了。成功的关键有三个-g编译、ulimit -c unlimited、core_pattern指向可写目录。三个条件缺一不可。3.2 实验二观察systemd-coredump接管后的行为很多发行版默认把core_pattern配成了systemd-coredump管道。这种情况下不修改配置直接跑上面的crash程序当前目录不会有core文件但systemd已经默默处理了。用coredumpctl就能看到所有接管记录$ coredumpctl list TIME PID UID GID SIG COREFILE EXE Sun 2025-01-15 10:21:33 CST 5678 1000 1000 11 /tmp/coredump-lab/crash用coredumpctl info查看具体进程信息$ coredumpctl info 5678 PID: 5678 UID: 1000 GID: 1000 Signal: 11 (SEGV) Timestamp: Sun 2025-01-15 10:21:33 CST Command: crash Executable: /tmp/coredump-lab/crash Control Group: /user.slice/... Module: ...还可以直接用coredumpctl gdb进入GDB调试环境省去了自己找core文件路径的麻烦coredumpctl gdb 5678这种方式更适合服务器场景因为systemd会把core压缩存储并自动附带崩溃进程的元数据。代价是你得花几秒钟熟悉coredumpctl的子命令有些老运维不喜欢它但我实测下来它比直接落盘更不容易丢文件。3.3 实验三从core文件中提取关键信息在打开GDB之前先用系统工具“望闻问切”一下能省很多时间。如果core_pattern是文件方式第一步先看文件类型$ file /tmp/coredump-lab/cores/core_crash_5678_1699000000如果显示ELF 64-bit LSB core file基本可以确认文件是完好的。接下来用readelf -n看崩溃信号$ readelf -n /tmp/coredump-lab/cores/core_crash_5678_1699000000 | head -20在NT_SIGINFO段能看到siginfo.si_signo是11即SIGSEGV。这能帮你快速判断到底是段错误、断言失败SIGABRT还是别的问题。有时候还能用strings在core文件里找到路径、环境变量甚至部分日志输出比如包含源代码路径或者加载的动态库列表。当然这些是辅助手段真正的重头戏在GDB。3.4 实验四用gdb还原崩溃现场现在进入核心环节。用GDB加载core文件gdb /tmp/coredump-lab/crash /tmp/coredump-lab/cores/core_crash_5678_1699000000进入GDB后先执行(gdb) bt #0 trigger_crash () at crash.c:4 #1 main () at crash.c:8只有两行栈原因一目了然第4行解引用了空指针。再看一下局部变量和寄存器(gdb) info locals No symbol table info available.如果你编译时带了-g这里会直接显示变量值。如果你是release包没有符号GDB会提示没有符号表。这也是为什么我反复强调-g的建议。查看崩溃点的源码(gdb) list 1 #include stdio.h 2 3 void trigger_crash(void) { 4 int *p NULL; 5 *p 1; 6 } 7 8 int main(void) { 9 printf(before crash\n); 10 trigger_crash();对于复杂程序还可以用frame N切换到任意调用层级查看当时的传参和变量。这比看日志推断要准确得多。4. 常见问题与排查技巧实录4.1 常见问题速查表我把这几年实际排查中遇到的高频问题整理成一个表纯经验向不涉及书本上的官方标准答案。现象可能原因处理办法程序崩溃但不显示“(core dumped)”ulimit -c为0执行ulimit -c unlimited显示“(core dumped)”但找不到core文件core_pattern指向systemd管道coredumpctl list查找或改core_patterncore文件生成在意外目录core_pattern没有占位符设置成/data/cores/core_%e_%pgdb加载core后bt只有地址没有函数名缺少调试符号安装debuginfo包或重新编译加-gcore文件非常大磁盘被写满进程内存占用太高RLIMIT_CORE过大设置合理的ulimit -c上限core文件权限是0600别的用户读不了内核按崩溃用户权限创建用崩溃时的用户分析或修改umasksystemd交付的core无法用gdb直接打开压缩格式路径在/var/lib/systemd/coredump用coredumpctl gdb PID这张表里最容易踩坑的就是第一行和第二行组合出现。shell里看到的ulimit -c是当前shell的如果你用脚本启动服务脚本里可能覆盖了设置。建议把ulimit -c unlimited写进服务启动脚本或者systemd unit文件里而不是指望交互shell。4.2 实战案例一段指针踩内存的定位过程有一次服务的某个接口偶发崩溃日志里只有一句Segmentation fault进程就被守护进程拉起来了。重启是好但问题还在。幸好当时开了systemd-coredump我用coredumpctl list找到了对应PID的core文件。先用GDB看栈回溯(gdb) bt #0 __free_hook () at /usr/lib/... #1 free () at /usr/lib/... #2 release_resource (ctx0x...) at resource.c:182 #3 ...崩溃点在free里这很典型几乎可以断定是堆被踩了。但是谁踩的呢GDB的栈只能看到free自己被调用看不到更早的越界写。此时我做了两件事。第一frame 2切到release_resource看它的参数和局部变量确认那个指针原本指向的内存块有多大。第二用x/32bx 指向的内存地址查看内存内容发现某个结构体后面的内容被一段ASCII字符串覆盖了。顺着这个字符串的来源我回到代码里搜发现是前一个分支里对某个buffer做了strcpy没有检查长度。一次缓冲区溢出把相邻结构体的指针覆盖了等到后面free时指针已经变成了字符串内容自然引发崩溃。整个过程没有core文件的话几乎不可能在几分钟内定位尤其是这种偶发问题。4.3 以“现场证据”为核心的排查心法做了那么多实验最大的心得就是coredump排查一定要当成刑侦现场来处理不能只凭经验猜。第一core文件是现场证据第一现场一定要保护好。进程崩溃后别急着重启如果开启了自动重启机制至少把core文件先拷出来再做处理。第二GDB里的bt不是万能的。栈被破坏、栈指针被改写时bt可能完全失效这时候要转而排查$pc寄存器、查看info registers、看看栈上剩余数据甚至用x/i $pc看崩溃指令的汇编。不要死磕栈回溯。第三符号表是决定排查效率的分水岭。线上环境建议安装对应版本号的debuginfo包或者编译时保留单独的符号文件用GDB的set debug-file-directory指向符号目录。没有符号表很多崩溃点只能看到一个裸地址虽然也能用addr2line配合映射表还原但效率天差地别。第四corrupted case里如果崩溃现场本身已经不可信可以试试在崩溃前实时抓取内存趋势或者用AddressSanitizer复现。ASan对很多缓冲区溢出类问题一针见血但还是那句话线上偶现问题往往没有机会插桩重跑这时core文件就是唯一保险。最后再分享一个我自己的习惯每次拿到core文件我会先看时间戳和崩溃进程的启动时间估算一下进程存活时长。这个信息经常和日志里的上下文对得上帮助我从时间线反推操作序列。真正把核心转储用好靠的不是某一条命令而是把每条命令背后的原理、每个配置项的含义都串起来。动手做过一遍你会对“进程为什么会死”这件事有完全不一样的感觉。