7、Valgrind内存检查：Memcheck检测内存泄漏、越界访问、使用未初始化内存

内存问题，是C语言开发者的噩梦。

我见过太多项目，上线后莫名其妙地崩溃，查了几天才发现是内存越界。还有一次，一个同事调了整整一周的bug，最后发现是用了未初始化的变量。说实话，这些坑我自己也踩过不少。

Valgrind的Memcheck工具，就是专门对付这些问题的。它像一个内存警察，帮你盯住每一块内存的申请、使用和释放。今天我们就来聊聊怎么用好它。

7.1 Memcheck的工作原理

Memcheck是怎么做到的？说白了，它拦截了你的malloc、free、memcpy这些内存操作函数。每次你申请内存，它都会记录这块内存的地址、大小、是否已初始化。每次你读写内存，它都会检查这个地址是否合法。

你想想看，这相当于给每块内存都配了一个“身份证”。非法访问？立刻抓现行。

7.2 内存泄漏检测

内存泄漏，就是申请了内存但没释放。程序跑得越久，泄漏越多，最后内存耗尽，进程被系统杀掉。

我个人习惯在开发阶段就定期跑Valgrind。尤其是服务端程序，跑个几天几夜，内存泄漏就全现形了。

7.2.1 典型泄漏场景

// 示例1：忘记释放
void leak_example() {
    int *p = (int*)malloc(100 * sizeof(int));
    // 用完了，但忘了 free(p)
}

// 示例2：丢失指针
void lost_pointer() {
    int *p = (int*)malloc(100 * sizeof(int));
    p = (int*)malloc(200 * sizeof(int));  // 第一次申请的100个int，指针丢了
    free(p);
}

// 示例3：条件分支漏释放
void conditional_leak(int flag) {
    int *p = (int*)malloc(100 * sizeof(int));
    if (flag) {
        return;  // 直接返回，没释放
    }
    free(p);
}

7.2.2 运行检测

# 编译时加 -g，保留调试信息
gcc -g -o test leak.c

# 运行Valgrind
valgrind --leak-check=full ./test

输出中你会看到类似这样的信息：

==12345== 400 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2B800: malloc (vg_replace_malloc.c:309)
==12345==    by 0x4005E7: leak_example (leak.c:4)
==12345==    by 0x4005F8: main (leak.c:12)

看到“definitely lost”了吗？这就是铁证如山的内存泄漏。Valgrind还贴心地告诉你在哪一行申请的。

7.3 越界访问检测

越界访问，就是读写了一块不属于你的内存。这种bug最恶心——有时候能跑，有时候崩，完全看运气。

我曾经在一个网络库中遇到过这种问题。程序跑了三天才崩溃，查堆栈完全看不出原因。最后用Valgrind一跑，发现是memcpy多拷贝了8个字节。

// 越界写入
void buffer_overflow() {
    char buf[10];
    for (int i = 0; i <= 10; i++) {  // 注意：i=10时越界
        buf[i] = 'A';
    }
}

// 越界读取
void buffer_overread() {
    int arr[5] = {1, 2, 3, 4, 5};
    int val = arr[5];  // 读取了arr[5]，越界
    printf("%d\n", val);
}

// 堆内存越界
void heap_overflow() {
    int *p = (int*)malloc(5 * sizeof(int));
    p[5] = 100;  // 越界
    free(p);
}

Valgrind检测到越界时，会输出类似：

==12345== Invalid write of size 4
==12345==    at 0x4005E7: heap_overflow (overflow.c:8)
==12345==  Address 0x5204044 is 0 bytes after a block of size 20 alloc'd
==12345==    at 0x4C2B800: malloc (vg_replace_malloc.c:309)
==12345==    by 0x4005D8: heap_overflow (overflow.c:7)

“Invalid write of size 4”说明你非法写了4个字节。“0 bytes after a block of size 20”说明你刚好在分配的内存后面写了一个字节。信息非常精确。

7.4 使用未初始化内存

这个坑更隐蔽。变量没初始化，里面存的是垃圾值。有时候垃圾值刚好是0，程序能跑；换台机器，垃圾值变了，程序就崩了。

// 局部变量未初始化
void uninit_local() {
    int x;
    if (x > 0) {  // x未初始化
        printf("positive\n");
    }
}

// 堆内存未初始化
void uninit_heap() {
    int *p = (int*)malloc(10 * sizeof(int));
    if (p[0] == 0) {  // p[0]未初始化
        printf("zero\n");
    }
    free(p);
}

// 结构体成员未初始化
struct Point {
    int x;
    int y;
};

void uninit_struct() {
    struct Point pt;
    printf("%d\n", pt.x);  // pt.x未初始化
}

Valgrind检测到未初始化内存使用时，会输出：

==12345== Conditional jump or move depends on uninitialised value(s)
==12345==    at 0x4005E7: uninit_local (uninit.c:4)
==12345==    by 0x4005F8: main (uninit.c:12)

“Conditional jump depends on uninitialised value”说明你的if判断依赖了一个未初始化的变量。Valgrind连这个都能抓到。

7.5 实用技巧与避坑指南

用Valgrind这么多年，我总结了几条经验：

• 编译时一定要加 -g -O0：-g保留调试信息，-O0关闭优化。优化后的代码行号可能对不上，排查起来很痛苦。
• 先跑小数据，再跑大数据：小数据跑得快，能快速发现明显问题。大数据跑得久，用来排查边界情况。
• 配合gdb使用：Valgrind发现错误后，可以用--vgdb-error=0参数，让程序在出错时暂停，然后用gdb attach上去看现场。

7.6 总结

Valgrind的Memcheck，说白了就是一个内存问题的照妖镜。内存泄漏、越界访问、未初始化内存，这三种最常见的bug，它都能帮你揪出来。

我个人建议，把Valgrind集成到你的CI流程里。每次提交代码都自动跑一遍，有问题直接拦截。这样能省下大量的调试时间。

嗯，内存问题就聊到这里。记住一句话：写代码时多一份小心，调试时少一份痛苦。

---

公众号:蓝海资料掘金营，微信deep3321