第三章 内存泄漏检测工具概述：Valgrind、AddressSanitizer、mtrace、dmalloc、自己写Hook

说到内存泄漏检测，很多刚入行的兄弟第一反应就是「加日志呗」。嗯，日志确实能解决问题，但效率嘛……你想想看，一个跑了几天的机顶盒，日志文件动不动就几百兆，你从里面翻出哪条内存没释放，那真是大海捞针。

所以，专业的事交给专业的工具。这一章，我就带你过一遍嵌入式开发里常用的几款内存泄漏检测工具。每个工具我都用过，踩过坑，也救过急。咱们一个一个说。

3.1 Valgrind：Linux下的瑞士军刀

Valgrind 是我个人最常用的工具之一。它本质上是一个虚拟机的框架，你的程序跑在它上面，所有内存操作都会被拦截和分析。

它的核心工具叫 Memcheck，专门检测内存泄漏、越界访问、使用未初始化内存等问题。

基本用法：

valgrind --tool=memcheck --leak-check=full ./your_program

跑完之后，它会给你一份详细的报告，告诉你哪块内存没释放，是在哪个文件的哪一行分配的。

优点：

  • 不需要重新编译程序（当然，加 -g 选项效果更好）
  • 检测非常全面，连字节级别的越界都能抓到

缺点：

  • 程序运行速度会慢 10-20 倍。我在项目中遇到过，一个原本 3 秒启动的机顶盒，用 Valgrind 跑了快一分钟
  • 对嵌入式平台支持有限，很多 ARM 交叉编译环境跑不了

我的经验：Valgrind 适合在开发阶段的 x86 模拟器上用。等代码稳定了，再交叉编译到目标板。别指望它在机顶盒真机上跑，资源不够。

3.2 AddressSanitizer (ASan)：编译器的守护神

AddressSanitizer 是 Google 搞出来的，现在集成在 GCC 和 Clang 里。它的思路和 Valgrind 完全不同——它是在编译阶段插入检测代码。

用法很简单，编译时加几个 flag 就行：

gcc -fsanitize=address -g -O1 -o my_program my_program.c

跑起来之后，一旦发生内存错误，程序会立刻崩溃，并打印出详细的调用栈。

优点：

  • 速度比 Valgrind 快得多，大概只慢 2-3 倍
  • 能检测出堆溢出、栈溢出、全局变量溢出、释放后使用等

缺点：

  • 需要重新编译代码
  • 对嵌入式交叉编译工具链的支持参差不齐。我记得有一次在某个老版本的 ARM GCC 上，ASan 根本编译不过去

注意：ASan 会显著增加二进制文件的大小，而且运行时内存占用也会翻倍。在资源紧张的机顶盒上，慎用。

3.3 mtrace：轻量级的 malloc 追踪器

mtrace 是 glibc 自带的一个小工具。它通过设置环境变量来记录每次 malloc 和 free 的调用。

用法分三步：

  1. 在代码里调用 mtrace() 和 muntrace() 包裹你要检测的代码段
  2. 设置环境变量 MALLOC_TRACE 指向一个日志文件
  3. 运行程序，然后用 mtrace 命令分析日志
export MALLOC_TRACE=/tmp/mtrace.log
./my_program
mtrace my_program /tmp/mtrace.log

优点：

  • 非常轻量，几乎不影响性能
  • 不需要额外安装工具，glibc 自带

缺点：

  • 只能检测内存泄漏，不能检测越界访问
  • 日志文件会非常大，如果程序频繁分配内存，几秒钟就能生成几百兆

我的建议：mtrace 适合在机顶盒真机上做快速验证。我曾经用它定位过一个只在特定频道切换时才会触发的泄漏，Valgrind 跑不出来，mtrace 反而抓到了。

3.4 dmalloc：老牌的内存调试库

dmalloc 是一个独立的内存调试库，需要下载编译。它通过替换 malloc/free 等函数，在运行时做各种检查。

用法：

gcc -DDMALLOC -DDMALLOC_FUNC_CHECK -o my_program my_program.c -ldmalloc

然后设置环境变量 DMALLOC_OPTIONS 来控制检测行为：

export DMALLOC_OPTIONS=debug=0x4f47d3,log=dmalloc.log
./my_program

优点：

  • 功能非常丰富，可以检测泄漏、越界、重复释放等
  • 支持多线程

缺点：

  • 配置复杂，环境变量那一串数字让人头大
  • 需要链接额外的库，对嵌入式交叉编译不太友好

避坑指南：我曾经在某个项目里用 dmalloc，结果发现它和机顶盒的底层驱动库有冲突，导致系统频繁崩溃。后来查了半天，才发现是 dmalloc 替换了 free 函数，而驱动库内部用了自己的内存管理。所以，用 dmalloc 之前，先确认你的整个软件栈都兼容。

3.5 自己写 Hook：终极掌控感

说实话，有时候现成的工具就是不好使。比如，你的机顶盒用的是裁剪过的 Linux 内核，glibc 都不全，Valgrind 和 ASan 根本跑不起来。这时候怎么办？

自己动手，写 Hook。

核心思路很简单：通过 dlsym 或 LD_PRELOAD 拦截 malloc、free、realloc 等函数，在每次分配和释放时记录地址和大小。

一个最简单的例子：

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

static void* (*real_malloc)(size_t) = NULL;

void* malloc(size_t size) {
    if (!real_malloc) {
        real_malloc = dlsym(RTLD_NEXT, "malloc");
    }
    void* ptr = real_malloc(size);
    fprintf(stderr, "malloc(%zu) = %p\n", size, ptr);
    return ptr;
}

void free(void* ptr) {
    if (!real_free) {
        real_free = dlsym(RTLD_NEXT, "free");
    }
    fprintf(stderr, "free(%p)\n", ptr);
    real_free(ptr);
}

编译成动态库，然后用 LD_PRELOAD 加载：

gcc -shared -fPIC -o mymalloc.so mymalloc.c -ldl
LD_PRELOAD=./mymalloc.so ./my_program

优点：

  • 完全可控，想记录什么就记录什么
  • 不依赖任何第三方库，适合各种嵌入式平台

缺点：

  • 开发工作量大，要处理多线程、信号安全等问题
  • 容易引入新的 bug，比如递归调用

我的经验：自己写 Hook 是我在机顶盒项目中最常用的方法。因为很多芯片厂商的 SDK 都是魔改过的，标准工具根本用不了。我一般会写一个轻量级的 Hook 库，只记录分配和释放的地址，然后定期打印出未释放的内存块。够用就好，别搞太复杂。

3.6 工具对比总结

说了这么多，最后给你一张表，方便你快速选择：

工具 检测类型 性能影响 嵌入式适用性 推荐场景
Valgrind 泄漏、越界、未初始化 极慢（10-20x） 低（需 x86 模拟） 开发阶段，x86 模拟器
AddressSanitizer 泄漏、越界、释放后使用 中等（2-3x） 中（需工具链支持） 编译阶段，集成测试
mtrace 泄漏 低 高（glibc 自带） 真机快速验证
dmalloc 泄漏、越界、重复释放 中等 中（需交叉编译） 功能丰富的调试场景
自己写 Hook 自定义 可控 极高 定制化需求，特殊平台

嗯，工具就这些。说白了，没有银弹。每个工具都有自己的脾气，你得根据项目实际情况来选。我个人习惯是：开发阶段用 Valgrind 或 ASan，真机调试用 mtrace 或自己写的 Hook。灵活搭配，才能事半功倍。

下一章，咱们就深入 Valgrind，看看怎么用它来定位一个真实的内存泄漏案例。

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