高阶嵌入式工程师必备：GDB+Core Dump 死机追踪核心方法论

在嵌入式Linux场景中，“系统死机”多数是用户态进程触发致命错误（如段错误、栈溢出） 导致的进程崩溃（表现为服务无响应、设备卡死），而GDB+Core Dump是定位这类死机根因的“黄金组合”——前者是调试工具，后者是崩溃现场快照，二者结合可高效还原死机瞬间的程序状态，精准定位问题。
掌握它，福尔摩斯 华生都会佩服你！

一、GDB & Core Dump 核心介绍（针对死机场景）

Coredump = 犯罪现场照片
GDB = 刑侦专家
二者结合 → 精准定位"案发地点"与"作案手法"

1. 🔍 GDB（GNU Debugger）

• 核心定位：跨平台调试工具，支持ARM/x86等架构，是嵌入式Linux下调试用户态程序的核心工具；
• 死机场景价值：无需实时调试（死机后进程已退出），可通过加载Core文件“复盘”崩溃现场，还原死机前的程序状态；
• 关键适配：嵌入式需用对应架构的GDB（如ARM64用gdb-multiarch/aarch64-linux-gnu-gdb），且程序编译时需加-g保留调试符号（否则无法解析函数/行号）。

2. 💾 Core Dump（核心转储）

• 核心功能：进程触发致命错误（如SIGSEGV/SIGABRT/SIGILL）导致死机时，操作系统将进程的内存镜像、寄存器状态、调用栈、线程信息 等保存到磁盘的二进制文件（即Core文件）；

• 死机场景价值：相当于“死机现场的黑匣子”，是事后定位死机根因的唯一有效手段（实时调试无法复现偶发死机时，Core Dump是关键）；

• 注意：

  • 仅保存用户态进程数据（内核态死机需分析内核panic日志，不在本文范围）；
  • 文件大小通常与进程占用内存相当（嵌入式需注意存储空间）。

二、Core Dump 生成原理

1. 触发条件（死机的本质）

进程触发Linux内核的“致命信号”时，内核会触发Core Dump（默认可能关闭），常见触发信号（对应死机场景）：

2. 内核处理流程（死机时Core Dump如何生成）

1. 进程触发致命信号 → 内核接收到信号并判断是否允许生成Core Dump；
2. 内核检查ulimit -c限制（默认0，禁止生成），若限制为“unlimited”则允许；
3. 内核根据/proc/sys/kernel/core_pattern配置的路径，创建Core文件；
4. 内核将进程的：
   • 虚拟内存布局（堆/栈/代码段/数据段）；
   • 寄存器状态（PC：程序计数器，SP：栈指针，LR：链接寄存器等）；
   • 线程信息（所有LWP的状态）；
   • 函数调用栈、局部变量值；
5. 写入Core文件，完成后终止进程（表现为系统死机/服务无响应）。
   

3. 关键限制

• 通过 ulimit -c 限制文件大小
• 通过 /proc/sys/kernel/core_pattern 控制保存路径
• 默认仅对有写权限的目录生成

三、完整配置流程

步骤1：配置系统允许生成Core Dump

若未配置，死机后不会生成Core文件，需提前在嵌入式设备执行：

# 1. 允许生成无大小限制的 core 文件
ulimit -c unlimited

# 2. 永久生效（写入 /etc/security/limits.conf）
* soft core unlimited
* hard core unlimited

# 3. 设置 core 文件命名规则（需 root）
echo "/tmp/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern
# `%e`：程序名
# `%p`：进程 ID
# `%h`：主机名
# `%t`：时间戳

# 4. 创建目录 & 赋权
sudo mkdir -p /var/crash
sudo chmod 1777 /var/crash  # sticky bit，允许所有用户写入

步骤 2：编译带调试符号的程序

# 关键：-g 保留调试符号，-O0 关闭优化
gcc -g -O0 -o critical_service service.c

⚠️ 非常使用小技巧：
保留带符号的二进制文件，部署时剥离符号（strip）提升性能，崩溃时用备份符号文件分析

步骤 3：触发崩溃并捕获 Coredump

# 运行程序（假设会因空指针崩溃）
./critical_service
# 输出：
# Segmentation fault (core dumped)
# 验证 core 文件生成
ls /var/crash/core.critical_service.12345.1650000000

步骤 4：使用 GDB 分析 Coredump

# 基础命令
gdb ./critical_service /var/crash/core.critical_service.12345.1650000000

# 或先进入 GDB 再加载
gdb ./critical_service
(gdb) core-file /var/crash/core.critical_service.12345.1650000000

四、GDB+Core Dump 实战演练！

案例代码 (crash.c)

#include <stdio.h>
#include <stdlib.h>

typedef struct {
    int id;
    char name[20];
} Device;

void process_device(Device *dev) {
    // 潜在问题：未检查空指针
    printf("Processing device %s (ID: %d)\n", dev->name, dev->id);
}

int main() {
    Device *device_list = malloc(10 * sizeof(Device));
    // 忘记初始化某些元素
    device_list[5].id = 1005;
    strcpy(device_list[5].name, "Sensor-X");

    // 错误：访问未初始化的 device_list[3]
    process_device(&device_list[3]); // 这里崩溃！

    free(device_list);
    return 0;
}

调试过程：

# 1. 编译并运行
gcc -g -o crash crash.c
./crash
# Segmentation fault (core dumped)

# 2. 用 GDB 分析
gdb ./crash core

GDB 交互分析：

root@linaro-alip:/var/crash# gdb /userapp/crash /var/crash/core.critical_service.12345.1650000000
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /userapp/crash ...done.

warning: exec file is newer than core file.
[New LWP 14400]
[New LWP 14502]
……
[New LWP 14407]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `/userapp/crash '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005555555551a1 in process_device () at /userapp/crash.c:11

[Current thread is 1 (Thread 0x7f508281c0 (LWP 14497))]
(gdb) bt  # 查看崩溃时的调用栈
#0  0x00005555555551a1 in process_device (dev=0x5555555592c0) at crash.c:11
#1  0x000055555555523b in main () at crash.c:23

(gdb) f 0  # 切换到崩溃帧
#0  0x00005555555551a1 in process_device (dev=0x5555555592c0) at crash.c:11
11          printf("Processing device %s (ID: %d)\n", dev->name, dev->id);

(gdb) p dev  # 检查关键变量
$1 = (Device *) 0x5555555592c0

(gdb) p *dev  # 解引用查看内容
$2 = {id = 0, name = '\000' <repeats 19 times>}  # 全是0！未初始化

(gdb) x/10x &device_list[3]  # 检查内存内容
0x5555555592c0: 0x00000000      0x00000000      0x00000000      0x00000000
0x5555555592d0: 0x00000000      0x00000000      0x00000000      0x00000000