3. 内存分析：栈溢出与堆泄漏的检测方法，内存映射文件分析，使用GDB查看内存布局

内存问题，可以说是嵌入式开发里最让人头疼的几类Bug之一。我做了这么多年嵌入式，见过太多同事被栈溢出和内存泄漏折磨得焦头烂额。说白了，这类Bug不像逻辑错误那样容易复现，它往往在系统运行几小时甚至几天后才突然爆发。今天我们就来系统地聊聊，怎么用工具和手段把这些藏在内存里的“鬼”揪出来。

3.1 栈溢出：无声无息的系统杀手

栈溢出，我习惯叫它“隐形炸弹”。为什么？因为它在发生之前，系统可能一切正常。突然某个函数递归深了一点，或者局部变量定义大了一点，啪，系统就挂了。

3.1.1 栈溢出的典型场景

• 递归调用过深：比如一个无限递归的二分查找，或者深度优先遍历没有限制层数。
• 局部变量过大：在函数里定义了一个几KB的数组，而任务栈总共才几KB。
• 中断嵌套：中断服务函数里又调用了可能触发中断的函数，导致栈空间被快速消耗。

3.1.2 检测方法：栈水印与栈指针检查

我在项目中常用的方法有两种。第一种是栈水印法，说白了就是在任务创建时，把整个栈空间填充一个固定模式（比如0xDEADBEEF）。等系统运行一段时间后，检查栈空间里还有多少水印没有被覆盖。如果剩余空间低于某个阈值，就报警。

// 栈水印初始化示例
#define STACK_PATTERN 0xDEADBEEF

void stack_watermark_init(uint32_t *stack_start, uint32_t stack_size) {
    for (uint32_t i = 0; i < stack_size / 4; i++) {
        stack_start[i] = STACK_PATTERN;
    }
}

// 检查栈使用深度
uint32_t stack_usage_check(uint32_t *stack_start, uint32_t stack_size) {
    uint32_t used = 0;
    for (uint32_t i = 0; i < stack_size / 4; i++) {
        if (stack_start[i] != STACK_PATTERN) {
            used++;
        } else {
            break;  // 遇到第一个未覆盖的水印就停止
        }
    }
    return used * 4;  // 返回已使用的字节数
}

第二种方法是硬件栈指针监测。有些MCU（比如Cortex-M系列）有硬件机制可以监测栈指针是否越界。我记得在做一个电机控制项目时，就是靠这个功能抓到了一个中断服务函数里的栈溢出。

3.2 堆泄漏：内存的“黑洞”

堆泄漏比栈溢出更隐蔽。栈溢出通常会导致立即崩溃，而堆泄漏是慢慢蚕食你的可用内存。系统可能运行几天后突然malloc失败，然后整个系统瘫痪。

3.2.1 堆泄漏的常见原因

• malloc/free不配对：申请了内存但忘记释放，或者释放了两次。
• 指针覆盖：把指向堆内存的指针重新赋值了，原来的内存块就再也找不回来了。
• 异常路径未释放：函数在正常路径释放了内存，但异常返回时忘了释放。

3.2.2 检测方法：内存钩子与统计

我个人的做法是，在开发阶段替换标准的malloc/free，用带统计功能的版本。每次malloc时记录调用位置（文件名+行号），每次free时删除记录。这样在程序退出时，如果还有未释放的记录，就能精确定位泄漏点。

// 简易内存泄漏检测钩子
typedef struct {
    void *addr;
    const char *file;
    int line;
} mem_record_t;

#define MAX_RECORDS 1024
static mem_record_t records[MAX_RECORDS];
static int record_count = 0;

void *debug_malloc(size_t size, const char *file, int line) {
    void *ptr = malloc(size);
    if (ptr && record_count < MAX_RECORDS) {
        records[record_count].addr = ptr;
        records[record_count].file = file;
        records[record_count].line = line;
        record_count++;
    }
    return ptr;
}

void debug_free(void *ptr) {
    for (int i = 0; i < record_count; i++) {
        if (records[i].addr == ptr) {
            // 移除记录
            records[i] = records[--record_count];
            break;
        }
    }
    free(ptr);
}

// 使用宏替换标准函数
#define malloc(s) debug_malloc(s, __FILE__, __LINE__)
#define free(p) debug_free(p)

3.3 内存映射文件分析

当系统崩溃后，如果能拿到一份内存映射文件（比如core dump或者map文件），那分析起来就事半功倍了。内存映射文件说白了就是系统在崩溃那一瞬间的内存快照。

3.3.1 链接器生成的map文件

编译链接时生成的.map文件，记录了每个变量、函数在内存中的具体地址。我经常用它来确认某个全局变量是否被意外覆盖。

段名称	起始地址	结束地址	大小	内容
.text	0x08000000	0x0801FFFF	128KB	代码段
.data	0x20000000	0x20000FFF	4KB	已初始化全局变量
.bss	0x20001000	0x20002FFF	8KB	未初始化全局变量
.heap	0x20003000	0x20006FFF	16KB	堆空间
.stack	0x20007000	0x20007FFF	4KB	栈空间

你看这个表格，如果某个指针的值落在了0x20007000~0x20007FFF范围，那它指向的就是栈空间。如果这个指针被当作堆内存来free，那肯定出问题。

3.3.2 Core Dump分析

对于Linux嵌入式系统，core dump文件是分析崩溃的利器。我曾经接手过一个项目，系统每天凌晨3点准时重启。拿到core dump后，用GDB加载，发现是一个定时器回调函数里访问了已经释放的内存。

# 加载core dump到GDB
arm-linux-gnueabihf-gdb ./my_app core.12345

# 查看崩溃时的调用栈
(gdb) bt
#0  0x76f4a8b0 in __memcpy () from /lib/libc.so.6
#1  0x08001234 in timer_callback (arg=0x20004560) at timer.c:45
#2  0x76f5cde0 in __run_timer () from /lib/librt.so.1

# 查看某个地址的内容
(gdb) x/32wx 0x20004560
0x20004560:	0xdeadbeef	0xdeadbeef	0xdeadbeef	0xdeadbeef

看到0xdeadbeef了吗？这就是我前面说的栈水印。说明这个地址的内存已经被释放并填充了水印，但定时器回调还在访问它。

3.4 使用GDB查看内存布局

GDB是嵌入式调试的瑞士军刀。我几乎每天都要用它来查看内存布局。下面几个命令是我用得最频繁的。

3.4.1 查看变量地址与内容

# 查看变量地址
(gdb) p &my_buffer
$1 = (uint8_t *) 0x20001000

# 查看内存内容（以16进制显示32个字）
(gdb) x/32wx 0x20001000
0x20001000:	0x00000001	0x00000002	0x00000003	0x00000004

# 查看内存内容（以字符串形式显示）
(gdb) x/s 0x20001000
0x20001000:	"Hello World"

3.4.2 查看栈帧信息

# 查看当前栈帧
(gdb) info frame
Stack level 0, frame at 0x20007fe0:
 pc = 0x8001234 in func_a (main.c:20)
 saved pc = 0x8005678
 called by frame at 0x20007fc0

# 查看栈上的局部变量
(gdb) info locals
temp = 42
buffer = 0x20007f80 "ABCD"

3.4.3 查看堆内存分配情况

对于使用newlib的嵌入式系统，可以通过查看__malloc_trim等符号来了解堆的状态。

# 查看堆的当前边界
(gdb) p __malloc_trim
$2 = {<text variable, no debug info>} 0x8000abc <__malloc_trim>

# 查看堆的起始和结束地址（需要符号表支持）
(gdb) p __heap_start
$3 = 0x20003000
(gdb) p __heap_end
$4 = 0x20007000

3.5 本章知识体系

下面这张图总结了内存分析的三个核心维度，以及它们之间的关联。你可以把它当作一个检查清单，遇到内存问题时就按这个思路排查。

3.6 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路。

• 不要相信“这个函数不会递归太深”：我曾经在一个协议栈解析函数里用了递归，测试时一切正常。结果现场数据包结构变了，递归深度直接爆栈。后来我改成迭代实现，再也没出过问题。
• malloc失败不一定是内存不够：有一次系统频繁malloc失败，我以为是堆太小。查了半天才发现是内存碎片化严重，堆里有很多小空洞，但连续的大块内存已经没有了。解决方案是改用固定大小内存池。
• GDB查看内存时注意字节序：ARM Cortex-M默认是小端模式。你用x/4bx看到的是0x01 0x00 0x00 0x00，但用x/1wx看到的是0x00000001。别搞混了。