4、内存分析：栈溢出检测、堆内存泄漏排查、内存对齐问题

内存问题，是嵌入式开发里最让人头疼的几类bug之一。说实话，我见过太多工程师在功能逻辑上花大量精力，结果系统跑着跑着就莫名其妙复位了，或者运行几天后性能突然下降。最后查下来，十有八九是内存出了问题。

这一章，我就把内存分析里最核心的三个问题讲透：栈溢出、堆泄漏、还有内存对齐。这三个问题，我在项目里都踩过坑，有的坑还挺深。

4.1 栈溢出检测

栈溢出，说白了就是函数调用层级太深，或者局部变量太大，把栈空间给撑爆了。系统会怎么样？轻则数据被踩坏，重则直接跑飞。

我记得有一次调试一个电机控制程序，系统运行几分钟后就死机。查了两天，最后发现是一个中断服务函数里定义了一个512字节的局部数组。嗯，那个平台的栈总共才1KB，一个中断就把栈占了一半多。

4.1.1 栈溢出的典型场景

  • 递归调用过深：嵌入式里我基本不用递归，除非你能精确计算深度
  • 局部变量过大：特别是大数组、结构体，一不小心就超了
  • 中断嵌套：多个中断嵌套时，每个中断都要占用栈空间
  • 函数调用链过长：A调B，B调C，C调D...每层都有开销

4.1.2 检测方法：栈水印法

我个人最常用的方法，就是栈水印。原理很简单：在系统初始化时，把整个栈区域填上一个固定模式的数据，比如0xDEADBEEF。然后定期检查这个模式被覆盖了多少。

// 栈水印初始化
#define STACK_SIZE   1024
#define STACK_PATTERN 0xDEADBEEF

uint32_t stack_area[STACK_SIZE / 4];

void stack_watermark_init(void) {
    for (int i = 0; i < STACK_SIZE / 4; i++) {
        stack_area[i] = STACK_PATTERN;
    }
}

// 检查栈使用情况
uint32_t stack_usage_check(void) {
    uint32_t used = 0;
    for (int i = STACK_SIZE / 4 - 1; i >= 0; i--) {
        if (stack_area[i] != STACK_PATTERN) {
            used = (i + 1) * 4;
            break;
        }
    }
    return used;
}
我的习惯：在调试阶段，我会用一个定时器每隔100ms检查一次栈使用峰值。如果峰值超过栈总大小的70%，我就会考虑加大栈或者优化代码。别等到溢出才处理，那时候数据已经被踩了。

4.1.3 硬件栈溢出检测

有些MCU有硬件栈溢出检测功能，比如ARM Cortex-M系列的MPU（内存保护单元）。你可以把栈区域设置成不可访问，一旦溢出就会触发异常。

// 使用MPU保护栈区域（Cortex-M示例）
void MPU_Stack_Protect_Init(void) {
    // 设置栈区域为不可访问
    MPU->RNR  = 0;                    // 使用区域0
    MPU->RBAR = (uint32_t)&stack_area; // 栈基地址
    MPU->RASR = (0x01 << 0) |         // 使能
                (0x03 << 1) |         // 全不可访问
                (0x00 << 4) |         // 允许特权访问
                (0x00 << 8) |         // 禁止子区域
                (0x09 << 16);         // 区域大小512字节
    MPU->CTRL = MPU_CTRL_ENABLE_Msk | MPU_CTRL_PRIVDEFENA_Msk;
}
注意：硬件保护虽然好，但会带来额外的中断开销。我曾经在一个高实时性项目里用了MPU保护，结果中断响应时间增加了20%。后来改成了软件水印法，效果也不错。

4.2 堆内存泄漏排查

堆内存泄漏，就是malloc了没free，或者new了没delete。在嵌入式系统里，这问题尤其隐蔽——系统可能运行几天甚至几周后才出问题。

我遇到过最离谱的一次，是一个通信协议栈，每次收到特定类型的报文就malloc一块内存，但释放条件写错了。结果系统跑了72小时后，堆空间耗尽，所有动态分配都失败了。

4.2.1 泄漏的常见原因

  • 忘记释放：分配了内存，但释放代码没写
  • 释放条件不满足：释放代码在某个分支里，但那个分支永远进不去
  • 指针被覆盖：分配的内存地址被新值覆盖，原来的地址丢了
  • 异常路径未处理：函数中途返回，释放代码没执行到

4.2.2 手动排查：记录分配信息

我习惯在调试阶段，自己写一个简单的内存分配跟踪模块。每次malloc时记录文件名、行号和大小，free时擦除记录。这样就能知道哪些内存没被释放。

// 简易内存泄漏检测
#define MAX_RECORDS 100

typedef struct {
    void *addr;
    uint32_t size;
    const char *file;
    uint32_t line;
    uint8_t used;
} mem_record_t;

mem_record_t mem_records[MAX_RECORDS];

void *debug_malloc(uint32_t size, const char *file, uint32_t line) {
    void *ptr = malloc(size);
    if (ptr) {
        for (int i = 0; i < MAX_RECORDS; i++) {
            if (!mem_records[i].used) {
                mem_records[i].addr = ptr;
                mem_records[i].size = size;
                mem_records[i].file = file;
                mem_records[i].line = line;
                mem_records[i].used = 1;
                break;
            }
        }
    }
    return ptr;
}

void debug_free(void *ptr) {
    free(ptr);
    for (int i = 0; i < MAX_RECORDS; i++) {
        if (mem_records[i].addr == ptr) {
            mem_records[i].used = 0;
            break;
        }
    }
}

// 打印未释放的内存
void debug_print_leaks(void) {
    for (int i = 0; i < MAX_RECORDS; i++) {
        if (mem_records[i].used) {
            printf("泄漏: %s:%d, 大小=%d\n",
                   mem_records[i].file,
                   mem_records[i].line,
                   mem_records[i].size);
        }
    }
}

// 使用宏替换标准malloc/free
#define malloc(s) debug_malloc(s, __FILE__, __LINE__)
#define free(p)   debug_free(p)
避坑指南：我曾经在一个项目里直接用宏替换了malloc/free，结果发现有些第三方库也用了malloc，导致记录信息混乱。后来我改成了弱符号覆盖，只替换自己代码里的分配函数。

4.2.3 静态分析工具

手动排查毕竟麻烦，我建议在项目里集成静态分析工具。比如PC-Lint、Coverity，或者开源的Cppcheck。这些工具能自动检测出常见的泄漏模式。

工具 特点 适用场景
PC-Lint 规则全面，可定制 大型项目，有预算
Cppcheck 开源免费，轻量 中小项目，快速检查
Coverity 深度分析，误报少 安全关键系统
Valgrind 运行时检测，功能强 Linux嵌入式系统

4.3 内存对齐问题

内存对齐，说白了就是数据在内存里的存放位置，要符合硬件的要求。比如一个4字节的int，它的地址必须是4的倍数。如果不满足，有些CPU会直接报错，有些虽然能运行但性能会下降。

我记得有一次调试一个传感器驱动，数据读出来总是错的。查了半天，发现是结构体里的成员没有对齐，导致DMA传输时数据错位了。

4.3.1 为什么需要对齐

  • 硬件要求：有些CPU（比如ARM）不支持非对齐访问，会触发异常
  • 性能考虑：对齐访问比非对齐快很多，可能差好几倍
  • 原子操作：对齐的数据才能保证原子读写的正确性

4.3.2 结构体对齐的坑

结构体对齐是最容易出问题的地方。编译器会在成员之间插入填充字节，以保证每个成员都对齐。但如果你没意识到这一点，就会踩坑。

// 这个结构体实际占多少字节？
typedef struct {
    uint8_t  a;    // 1字节
    uint32_t b;    // 4字节
    uint16_t c;    // 2字节
} misaligned_t;

// 实际布局（假设4字节对齐）：
// 偏移0: a (1字节)
// 偏移1-3: 填充 (3字节)
// 偏移4: b (4字节)
// 偏移8: c (2字节)
// 偏移10-11: 填充 (2字节)
// 总大小: 12字节

// 优化后的结构体
typedef struct {
    uint32_t b;    // 4字节，放前面
    uint16_t c;    // 2字节
    uint8_t  a;    // 1字节
    // 偏移7: 填充 (1字节)
    // 总大小: 8字节
} aligned_t;
关键点：结构体成员按从大到小排列，可以减少填充字节。这不是什么高深技巧，但很多新手会忽略。我一般会在结构体定义后面加个静态断言，确保大小符合预期。

4.3.3 强制对齐与packed

有时候我们需要取消对齐，比如和硬件寄存器通信时，数据是紧密排列的。这时候可以用packed属性。

// 取消对齐，紧密排列
typedef struct __attribute__((packed)) {
    uint8_t  a;
    uint32_t b;
    uint16_t c;
} packed_t;

// 此时大小 = 1 + 4 + 2 = 7字节
// 但访问b时可能非对齐，性能会下降

// 更好的做法：手动对齐
typedef struct {
    uint8_t  a;
    uint8_t  padding[3];  // 手动填充
    uint32_t b;
    uint16_t c;
} manual_aligned_t;
警告：packed结构体虽然省空间，但访问非对齐成员时，有些CPU会触发异常。我建议只在和硬件通信的场景下使用packed，而且访问成员时要小心。如果性能敏感，还是手动填充更靠谱。

4.3.4 对齐检测与调试

调试对齐问题，我一般用这几个方法：

  • 打印地址：检查指针地址是否能被对齐大小整除
  • 使用静态断言：编译时检查结构体大小是否符合预期
  • 查看map文件：看编译器实际分配的内存布局
// 静态断言检查对齐
#define ASSERT_ALIGNMENT(type, alignment) \
    _Static_assert(sizeof(type) % alignment == 0, \
                   "Type " #type " is not aligned to " #alignment)

// 使用示例
ASSERT_ALIGNMENT(aligned_t, 4);

// 运行时检查地址对齐
#define IS_ALIGNED(ptr, alignment) \
    (((uintptr_t)(ptr) & ((alignment) - 1)) == 0)

void check_alignment(void *ptr, uint32_t alignment) {
    if (!IS_ALIGNED(ptr, alignment)) {
        printf("警告: 指针 %p 未对齐到 %d 字节\n", ptr, alignment);
    }
}

嗯，内存分析这块内容不少，但核心就是这三件事：栈别溢出、堆别泄漏、对齐别搞错。我建议你在项目初期就把这些检测机制加进去，别等到出问题了再回头查。那时候，你可能连问题出在哪都不知道。

下一章，我们会讲定时器与PWM的调试技巧。到时候我会分享一个我调了整整一周的PWM相位问题，保证让你有收获。

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