第4章工具准备

4、工具准备：搭建你的显存泄漏检测实验室

好，咱们进入正题。工欲善其事，必先利其器。显存泄漏检测这件事，光靠肉眼看代码，说实话效率太低了。你需要一套趁手的工具，帮你把那些藏得很深的内存黑洞一个个揪出来。

这一章，我就带你搭建一个完整的显存泄漏检测实验室。我会介绍几款我这些年用下来觉得最靠谱的工具，包括它们的优缺点、适用场景，以及怎么交叉编译到嵌入式平台。嗯，这部分实操性很强，建议你跟着一步步来。

4.1 必备工具一览

先列个清单，看看我们实验室里要准备哪些家伙。我按使用频率和重要性排了个序：

工具名称	主要用途	适用平台	我的推荐指数
Valgrind (Massif)	堆内存分析、泄漏检测	Linux (ARM/x86)	★★★★★
GPerfTools (TCMalloc)	轻量级内存剖析	Linux (ARM/x86)	★★★★☆
NVIDIA Nsight	GPU显存与性能分析	Jetson系列	★★★★★
Mali Graphics Debugger	Mali GPU显存跟踪	ARM Mali GPU	★★★★☆
自定义Hook库	malloc/free拦截	全平台	★★★★☆

你可能会问，为什么需要这么多工具？其实每个工具都有自己的脾气。Valgrind 功能强大但跑得慢，GPerfTools 轻量但功能有限，Nsight 和 Mali Debugger 专攻 GPU 显存。说白了，没有万能钥匙，你得学会组合使用。

4.2 Valgrind (Massif) —— 堆内存分析的瑞士军刀

Valgrind 是我个人最常用的工具之一。它里面的 Massif 工具专门做堆内存分析，能精确告诉你每个函数分配了多少内存，什么时候分配的，有没有释放。

我在项目中遇到过这样一个坑：一个视频处理管线，运行几小时后突然崩溃。用 Valgrind 一跑，发现有个中间缓冲区只分配不释放，每次处理一帧就泄漏 4MB。嗯，这种问题靠肉眼排查，你得看到猴年马月去。

核心用法：

# 基本用法
valgrind --tool=massif ./your_application

# 生成massif.out.12345文件后，用ms_print查看
ms_print massif.out.12345

交叉编译到嵌入式平台时，要注意几点：

目标平台的架构（ARMv7、ARMv8、AArch64）必须匹配
需要目标平台的交叉编译工具链，比如 arm-linux-gnueabihf-gcc
Valgrind 依赖 libc 和内核头文件，版本不能差太多

我的交叉编译步骤：

# 1. 下载源码
wget https://sourceware.org/pub/valgrind/valgrind-3.22.0.tar.bz2
tar -xjf valgrind-3.22.0.tar.bz2
cd valgrind-3.22.0

# 2. 配置交叉编译
./configure --host=arm-linux-gnueabihf \
            --prefix=/opt/valgrind-arm \
            CC=arm-linux-gnueabihf-gcc \
            CXX=arm-linux-gnueabihf-g++

# 3. 编译并安装
make -j4
make install

# 4. 将编译好的二进制拷贝到目标板
scp -r /opt/valgrind-arm/* root@192.168.1.100:/usr/local/

我曾经在编译时踩过一个坑：目标板的 glibc 版本太老，Valgrind 编译出来的工具链不兼容。后来我学乖了，编译前先用 ldd --version 确认目标板的 libc 版本，再选择对应的 Valgrind 版本。

4.3 GPerfTools —— 轻量级内存剖析

Valgrind 虽好，但跑起来实在太慢了。有时候你的程序本身就很吃性能，再用 Valgrind 跑，速度能降到原来的十分之一。这时候，GPerfTools 就派上用场了。

GPerfTools 是 Google 开源的性能分析工具集，其中的 TCMalloc 组件可以替代系统的 malloc/free，并提供内存剖析功能。说白了，它比 Valgrind 轻量得多，适合在生产环境或性能敏感的场景下使用。

使用方式：

# 链接TCMalloc
g++ -o my_app my_app.cpp -ltcmalloc

# 运行时启用内存剖析
env HEAPPROFILE=/tmp/heap.prof ./my_app

# 用pprof分析结果
pprof --text ./my_app /tmp/heap.prof.0001.heap

交叉编译时，GPerfTools 比 Valgrind 简单一些：

# 交叉编译GPerfTools
./configure --host=arm-linux-gnueabihf \
            --prefix=/opt/gperftools-arm \
            CC=arm-linux-gnueabihf-gcc \
            CXX=arm-linux-gnueabihf-g++ \
            --enable-frame-pointers

make -j4
make install

注意：GPerfTools 的 --enable-frame-pointers 选项在 ARM 平台上很重要。如果不开启，生成的调用栈信息可能不完整，分析结果会大打折扣。我刚开始用的时候就吃过这个亏，分析出来的数据全是问号，根本没法用。

4.4 NVIDIA Nsight —— GPU 显存分析的利器

如果你的嵌入式平台用的是 NVIDIA Jetson 系列（比如 TX2、Xavier、Orin），那 Nsight 就是你的不二之选。它能精确跟踪 GPU 上的显存分配和释放，包括 CUDA 和 TensorRT 的显存使用情况。

Nsight 的使用相对简单，因为它本身就是为嵌入式平台设计的：

在 Jetson 设备上安装 Nsight 命令行工具：sudo apt install nvidia-nsight
在 PC 上安装 Nsight Desktop 进行远程调试
通过 nsys 命令进行显存跟踪

显存泄漏检测命令：

# 跟踪显存分配
nsys profile --trace=cuda,nvtx -o ./report ./your_app

# 生成可视化报告
nsys stats ./report.qdrep

我个人习惯在开发阶段先用 Nsight 跑一轮，看看显存分配曲线是不是一直往上走。如果曲线是阶梯状上升但从不下降，那基本可以断定有泄漏了。

4.5 Mali Graphics Debugger —— ARM GPU 的守护神

对于使用 ARM Mali GPU 的嵌入式平台（比如 RK3588、树莓派 4B），Mali Graphics Debugger 是官方推荐的调试工具。它能捕获 GPU 的 API 调用，包括 OpenGL ES 和 Vulkan 的显存操作。

使用步骤：

在 PC 上安装 Mali Graphics Debugger 桌面版
在目标板上运行 Mali 的追踪服务
通过 USB 或网络连接 PC 和目标板
在 PC 上实时查看显存分配情况

小技巧：Mali Graphics Debugger 可以设置断点，在每次显存分配时暂停。我曾经用这个功能，一步步跟踪到一个纹理对象被重复创建了 100 多次，每次都没释放。嗯，这种问题用静态分析根本发现不了。

4.6 自定义 Hook 库 —— 最后的防线

有时候，商业工具覆盖不到你的场景。比如你用的 GPU 是自研的，或者显存分配走的是私有接口。这时候，你就得自己动手写一个 Hook 库了。

原理很简单：通过 LD_PRELOAD 环境变量，拦截 malloc、free、calloc、realloc 等内存分配函数，记录每次分配的地址和大小。当程序退出时，打印出所有未释放的内存块。

一个简单的 Hook 库示例：

// mem_hook.c
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

typedef void* (*malloc_t)(size_t size);
malloc_t real_malloc = NULL;

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

// 编译成共享库
// gcc -shared -fPIC -o libmemhook.so mem_hook.c -ldl

使用方式：

export LD_PRELOAD=/path/to/libmemhook.so
./your_application 2>mem_trace.log

交叉编译时，记得用目标平台的编译器：

arm-linux-gnueabihf-gcc -shared -fPIC -o libmemhook.so mem_hook.c -ldl

注意：Hook 库虽然灵活，但也有一些限制。比如它只能拦截用户态的 malloc/free，对于 GPU 驱动内部通过 ioctl 分配的显存，Hook 库是看不到的。这时候还是得用 Nsight 或 Mali Debugger 这类专用工具。

4.7 工具选择策略

说了这么多，你可能会问：到底该用哪个？我的建议是这样的：

开发初期：用 Valgrind 做全面检查，虽然慢但查得细
性能调优阶段：换 GPerfTools，轻量快速
GPU 相关：根据平台选 Nsight 或 Mali Debugger
特殊场景：自己写 Hook 库兜底

好了，工具准备就绪。下一章，我们就开始动手，用这些工具去抓几个真实的显存泄漏案例。到时候你会发现，这些工具用熟了，排查泄漏就像玩找茬游戏一样简单。

📚 课程目录

4、工具准备：搭建你的显存泄漏检测实验室

4.1 必备工具一览

4.2 Valgrind (Massif) —— 堆内存分析的瑞士军刀

4.3 GPerfTools —— 轻量级内存剖析

4.4 NVIDIA Nsight —— GPU 显存分析的利器

4.5 Mali Graphics Debugger —— ARM GPU 的守护神

4.6 自定义 Hook 库 —— 最后的防线

4.7 工具选择策略