4. 内存故障定位：内存泄漏检测、栈溢出检测、堆栈回溯（Backtrace）、内存访问越界检测

内存问题，是嵌入式开发里最让人头疼的几类故障之一。我见过不少同事，花了一两周去查一个随机死机的问题，最后发现是内存越界写坏了一个关键指针。说实话，这类问题如果靠肉眼一行行看代码，效率极低。我们需要一套系统的方法和工具。

这一章，我会把内存故障分成四类来讲：泄漏、栈溢出、堆栈回溯、越界访问。每一类我都会结合项目中的实际案例，告诉你我是怎么定位的。

核心观点： 内存故障的定位，本质上是「状态对比」和「行为追踪」。你不需要记住所有API，但必须理解故障的根因模型。
内存故障分类与定位流程 内存故障 内存泄漏 栈溢出 堆栈回溯 内存越界 统计malloc/free 栈指针监测 LR/PC回溯 Canary/MPU 💡 定位原则 • 内存泄漏：关注「分配-释放」配对，用统计法或钩子法 • 栈溢出：关注栈指针是否越界，用Canary或栈填充模式 • 堆栈回溯：关注LR/PC寄存器，用Backtrace解析调用链 • 内存越界：关注写入地址是否合法，用MPU或Canary保护

4.1 内存泄漏检测

内存泄漏，说白了就是「只借不还」。每次malloc一块内存，用完没有free，久而久之堆空间就被吃光了。在资源紧张的MCU上，可能几个小时就挂了。

我习惯用两种方法来查泄漏：统计法和钩子法。

4.1.1 统计法：记录分配与释放的差值

最简单的方式，是维护一个全局计数器。每次malloc加1，每次free减1。如果系统空闲时这个计数器不为0，那肯定有泄漏。

// 简易内存泄漏检测
static int g_malloc_count = 0;

void *my_malloc(size_t size) {
    void *ptr = malloc(size);
    if (ptr) {
        g_malloc_count++;
        // 可选：记录调用地址
    }
    return ptr;
}

void my_free(void *ptr) {
    if (ptr) {
        free(ptr);
        g_malloc_count--;
    }
}

// 定时打印
void mem_leak_check(void) {
    printf("[MEM] 当前未释放块数: %d\n", g_malloc_count);
}
我的习惯： 在产品的调试版本里，我会把malloc/free全部替换成带计数和调用栈记录的版本。这样一旦发现泄漏，直接就能定位到是哪次分配没释放。

4.1.2 钩子法：替换malloc/free

如果你用的是GCC，可以用--wrap选项来拦截malloc/free。这样不用改业务代码，就能统计所有堆操作。

// 链接选项: -Wl,--wrap,malloc -Wl,--wrap,free

void *__wrap_malloc(size_t size) {
    void *ptr = __real_malloc(size);
    // 记录分配信息
    log_malloc(ptr, size);
    return ptr;
}

void __wrap_free(void *ptr) {
    // 记录释放信息
    log_free(ptr);
    __real_free(ptr);
}

我在一个物联网网关项目里用过这个方法。当时设备运行三天后必死，用钩子法一查，发现是一个定时器回调里每次都会malloc一个缓冲区，但只在特定条件下才free。修复后设备稳定运行了半年多。

4.2 栈溢出检测

栈溢出比内存泄漏更隐蔽。它不会立刻报错，而是悄悄覆盖掉相邻的局部变量、返回地址，甚至其他任务的栈空间。等到出问题时，现场已经被破坏得差不多了。

我常用的检测手段有两种：Canary（金丝雀）和栈填充模式。

4.2.1 Canary检测

在任务栈的底部（高地址端）放一个已知的魔数，然后在任务切换或退出时检查这个魔数是否被改写。如果变了，说明栈溢出了。

#define STACK_CANARY 0xDEADBEEF

void task_stack_init(uint32_t *stack_base, int size) {
    // 在栈底写入Canary
    stack_base[size - 1] = STACK_CANARY;
}

int check_stack_overflow(uint32_t *stack_base, int size) {
    if (stack_base[size - 1] != STACK_CANARY) {
        printf("[FATAL] 栈溢出检测到！栈底Canary被破坏\n");
        return 1;
    }
    return 0;
}
注意： Canary只能检测到「已经发生」的溢出。它不能防止溢出，只能帮你尽早发现。我建议在调试阶段把Canary检查放在所有可能递归或深层调用的地方。

4.2.2 栈填充模式

另一种方法，是在任务创建时把整个栈空间填充成一个固定模式（比如0xCC）。然后定期扫描栈空间，看有多少字节被改写了。这样可以估算出栈的实际使用深度，帮你合理设置栈大小。

// 栈填充初始化
void stack_fill_init(uint32_t *stack_base, int size) {
    for (int i = 0; i < size; i++) {
        stack_base[i] = 0xCCCCCCCC;
    }
}

// 计算栈使用深度
int stack_usage_depth(uint32_t *stack_base, int size) {
    int depth = 0;
    for (int i = size - 1; i >= 0; i--) {
        if (stack_base[i] != 0xCCCCCCCC) {
            depth = size - i;
            break;
        }
    }
    return depth;
}

我曾经在一个多任务系统中，用这个方法发现一个任务的栈使用率高达95%。当时任务栈只给了512字节，实际用了480多。后来我把栈扩大到1024，系统就再也没出过莫名其妙的死机。

4.3 堆栈回溯（Backtrace）

堆栈回溯，就是当程序崩溃时，把当前函数调用链打印出来。它能告诉你「死在哪里」以及「怎么走到这里的」。在ARM Cortex-M上，我常用两种方式：基于FP的链式回溯和基于LR的精确回溯。

4.3.1 基于FP的链式回溯

每个函数入口处，编译器会保存上一帧的FP（帧指针）。通过FP链，我们可以一路回溯到main函数。

// ARM Cortex-M 简易Backtrace
void backtrace_fp(void) {
    uint32_t *fp;
    uint32_t lr, pc;

    __asm volatile("mov %0, r7" : "=r"(fp)); // 获取当前FP

    printf("[Backtrace] 调用链:\n");
    for (int i = 0; i < 10; i++) {
        if ((uint32_t)fp < 0x20000000 || (uint32_t)fp > 0x20020000) {
            break; // 地址异常，停止
        }
        lr = fp[1];  // 返回地址
        pc = fp[5];  // 上一帧的PC（取决于编译器）
        printf("  #%d: 0x%08X (LR=0x%08X)\n", i, pc, lr);
        fp = (uint32_t *)fp[0]; // 上一帧的FP
    }
}
避坑指南： 我曾经在优化等级开到-O2时，发现FP链断了。因为编译器优化后可能省略帧指针。解决办法是：调试版本用-O0或-Og，并加上-fno-omit-frame-pointer。

4.3.2 基于LR的精确回溯

如果编译器没有生成FP链，我们可以利用LR（链接寄存器）来回溯。在ARM上，每个非叶子函数都会把LR压栈。通过扫描栈上的LR值，也能还原调用链。

// 基于LR的Backtrace
void backtrace_lr(uint32_t *stack_top, uint32_t *stack_bottom) {
    printf("[Backtrace] 扫描栈上的LR:\n");
    int idx = 0;
    for (uint32_t *sp = stack_top; sp < stack_bottom; sp++) {
        uint32_t val = *sp;
        // 检查是否在代码区
        if (val >= 0x08000000 && val <= 0x080FFFFF) {
            printf("  #%d: 0x%08X\n", idx++, val);
        }
    }
}

这个方法有个缺点：栈上可能残留旧数据，导致误判。我一般只在HardFault处理函数里用，配合MPU保护，效果还不错。

4.4 内存访问越界检测

内存越界，就是写数据时超出了目标缓冲区的边界。它可能破坏相邻的变量、堆管理结构，甚至其他任务的栈。定位起来非常棘手。

我常用的方法有：Canary缓冲区和MPU硬件保护。

4.4.1 Canary缓冲区

在每个缓冲区的头部和尾部各放一个Canary。如果越界写，就会破坏Canary。在释放或检查时验证Canary是否完好。

#define CANARY_SIZE 4
#define CANARY_HEAD 0xA5A5A5A5
#define CANARY_TAIL 0x5A5A5A5A

void *safe_malloc(size_t size) {
    // 多分配8字节用于Canary
    uint8_t *ptr = (uint8_t *)malloc(size + CANARY_SIZE * 2);
    if (!ptr) return NULL;

    // 写入头部Canary
    *(uint32_t *)ptr = CANARY_HEAD;
    // 写入尾部Canary
    *(uint32_t *)(ptr + CANARY_SIZE + size) = CANARY_TAIL;

    // 返回有效数据区起始地址
    return (void *)(ptr + CANARY_SIZE);
}

int check_buffer_overflow(void *user_ptr, size_t size) {
    uint8_t *ptr = (uint8_t *)user_ptr - CANARY_SIZE;
    if (*(uint32_t *)ptr != CANARY_HEAD) {
        printf("[ERROR] 缓冲区头部越界！\n");
        return 1;
    }
    if (*(uint32_t *)(ptr + CANARY_SIZE + size) != CANARY_TAIL) {
        printf("[ERROR] 缓冲区尾部越界！\n");
        return 1;
    }
    return 0;
}
注意： Canary缓冲区只能检测「已知大小」的越界。如果越界发生在两个缓冲区之间，且没有破坏Canary，那就检测不到。所以它不能替代严谨的代码审查。

4.4.2 MPU硬件保护

如果你的MCU支持MPU（内存保护单元），那是最好的方案。MPU可以为每个内存区域设置访问权限。一旦越界访问，CPU会立刻触发异常，精确报告出错的地址和指令。

// MPU配置示例（Cortex-M4）
void mpu_config_buffer_protect(void *buf, uint32_t size) {
    MPU->RNR  = 0;           // 使用region 0
    MPU->RBAR = (uint32_t)buf & 0xFFFFFFE0; // 基地址（32字节对齐）
    MPU->RASR = (0x03 << 24) |  // 全权限（读/写）
                (0x01 << 18) |  // 允许执行
                (0x00 << 16) |  // 不共享
                (0x1F << 1)  |  // 大小：2^(1+31) = 4GB（实际按需）
                (0x01 << 0);    // 使能

    // 注意：实际项目中需要根据缓冲区大小计算RASR的SIZE字段
}

我在一个工业控制器项目里用过MPU。当时有一个周期性任务会随机写坏全局变量。我开了MPU保护，把关键数据区设为只读。结果不到10分钟，MPU就捕获到了非法写入——是一个野指针在作怪。

4.5 综合对比

故障类型 检测手段 优点 缺点 适用场景
内存泄漏 统计法/钩子法 实现简单，定位准确 需要替换malloc/free 所有使用动态内存的系统
栈溢出 Canary/栈填充 低开销，可在线检测 只能检测已发生的溢出 多任务RTOS系统
堆栈回溯 FP链/LR扫描 崩溃时快速定位 受编译器优化影响 HardFault调试
内存越界 Canary/MPU 硬件级保护，精确 MPU需要硬件支持 安全关键系统

嗯，这一章的内容就到这里。内存故障定位，说白了就是「防」和「查」的结合。防，靠MPU、Canary这些硬件或软件手段；查，靠Backtrace、统计法这些事后分析工具。你在实际项目中，可以根据资源情况和安全等级，选择合适的组合。

← 上一章 📖 返回目录 下一章 →