4. 动态分析工具入门：Valgrind Memcheck的安装、基本命令与报告解读
内存泄漏这东西，静态分析能帮你揪出一部分，但真正跑起来才会暴露更多问题。我见过太多代码，编译零警告，一跑就崩。这时候，你就需要一把手术刀——Valgrind 的 Memcheck 工具。
说白了，Memcheck 就是一个运行时检测器。它拦截你的程序每次内存分配和释放，检查有没有越界、重复释放、使用未初始化内存，以及最让人头疼的——内存泄漏。今天我们就把它装好、跑通、看懂报告。
4.1 安装 Valgrind：别踩我踩过的坑
安装本身不复杂，但不同平台有细微差别。我曾在某个老旧的 ARM 开发板上折腾了半天，才发现是内核版本太低。
4.1.1 Ubuntu/Debian 系
sudo apt-get update
sudo apt-get install valgrind4.1.2 CentOS/RHEL 系
sudo yum install valgrind4.1.3 从源码编译（嵌入式交叉编译场景）
这是重点。你开发板是 ARM，PC 是 x86，必须交叉编译。我曾经因为没指定 --host，导致在板子上跑出来的报告全是乱码。
# 下载源码
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
# 配置交叉编译环境
./configure --host=arm-linux-gnueabihf --prefix=/path/to/install
# 编译并安装
make
make install4.2 基本命令：从跑起来到看懂
安装完，第一件事就是验证。我个人习惯先跑一个最简单的程序，确认工具链没问题。
valgrind --tool=memcheck ./your_program嗯，就这么简单。但实际工作中，你不可能只看默认输出。下面这几个参数，是我每次必加的：
| 参数 | 作用 | 我的建议 |
|---|---|---|
--leak-check=full |
显示每个泄漏的详细信息 | 必加，否则只告诉你泄漏了多少字节 |
--show-leak-kinds=all |
显示 definite、indirect、possible、reachable 四种泄漏 | 必加，definite 是铁证，possible 需要人工判断 |
--track-origins=yes |
追踪未初始化值的来源 | 调试“野值”时必开，但会慢 2-3 倍 |
--log-file=valgrind.log |
输出到文件，避免终端刷屏 | 嵌入式开发必用，串口输出太慢 |
一个完整的命令长这样：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes --log-file=memcheck.log ./your_programvalgrind ... ./your_program arg1 arg2。
4.3 报告解读：别被吓到，其实就几类
第一次看 Memcheck 报告，你可能会觉得信息量太大。别慌，我教你拆解。报告主要分三块：内存越界、使用未初始化值、内存泄漏。
4.3.1 非法读写（Invalid read/write）
这是最常见的错误。你访问了不属于你的内存。
==12345== Invalid write of size 4
==12345== at 0x4005E4: main (example.c:10)
==12345== Address 0x5204040 is 0 bytes after a block of size 10 alloc'd
==12345== at 0x4C2B0E0: malloc (vg_replace_malloc.c:380)
==12345== by 0x4005D5: main (example.c:8)看到没？它告诉你：你在 example.c:10 写了一个 4 字节的值，但地址 0x5204040 是在 example.c:8 分配的 10 字节之后。说白了，你越界了。
4.3.2 使用未初始化值（Conditional jump or move depends on uninitialised value）
这个错误很隐蔽。你声明了一个变量没赋值，就直接拿来用。
==12345== Conditional jump or move depends on uninitialised value(s)
==12345== at 0x4005F0: main (example.c:15)如果你加了 --track-origins=yes，它会告诉你这个未初始化的值是从哪里来的。我曾经靠这个参数，找到了一个藏在三层函数调用深处的未初始化结构体。
4.3.3 内存泄漏（Memory leak）
这是我们的主菜。Memcheck 把泄漏分成四类：
| 类型 | 含义 | 处理优先级 |
|---|---|---|
| definitely lost | 指针丢失，内存永远无法释放 | 最高，必须修复 |
| indirectly lost | 结构体内部的指针丢失 | 高，通常伴随 definitely lost |
| possibly lost | 指针指向了某个内存块的内部 | 中，需要人工确认 |
| still reachable | 指针还在，但程序退出前没释放 | 低，但长期运行的程序必须处理 |
看一个典型的泄漏报告：
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345== at 0x4C2B0E0: malloc (vg_replace_malloc.c:380)
==12345== by 0x4005D5: create_buffer (example.c:20)
==12345== by 0x4005F0: main (example.c:30)它告诉你：在 create_buffer 函数第 20 行分配了 40 字节，但没人释放。你顺着调用栈去找，十有八九是忘了调用 free。
4.4 实战案例：一个简单的泄漏定位
光说不练假把式。我们写一个故意泄漏的程序，然后定位它。
// leak_demo.c
#include <stdlib.h>
void create_leak() {
int *p = (int *)malloc(10 * sizeof(int));
// 忘记 free(p)
}
int main() {
create_leak();
return 0;
}编译并运行 Memcheck：
gcc -g -o leak_demo leak_demo.c
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./leak_demo输出结果：
==12345== HEAP SUMMARY:
==12345== in use at exit: 40 bytes in 1 blocks
==12345== total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==12345==
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345== at 0x4C2B0E0: malloc (vg_replace_malloc.c:380)
==12345== by 0x40055A: create_leak (leak_demo.c:4)
==12345== by 0x40056A: main (leak_demo.c:9)看到了吗？create_leak 函数第 4 行分配的内存没释放。修复方法就是在函数末尾加一句 free(p)。
4.5 知识体系：Valgrind Memcheck 工作流程
下面这张图，帮你理清 Memcheck 的整个工作流程。从程序启动到报告生成，每一步都在干什么。
这张图的核心逻辑很简单：Memcheck 在你的程序和操作系统之间加了一层“影子内存”，记录每一块内存的状态。每次读写，它都会查一下这块内存是否合法。这就是为什么你的程序会变慢——它多了一个“警察”在盯着。
4.6 本章小结
Valgrind Memcheck 是嵌入式内存调试的基石。你不需要记住所有参数，但必须掌握：安装、基本命令、报告解读。尤其是报告里的 definitely lost，看到它就要立刻修复。