必须加 -g 才能定位泄漏位置，因Valgrind依赖调试符号将内存地址映射到源码行号；未加-g则仅显示内部路径如vg_replace_malloc.c；同时需用-O0关闭优化、--leak-check=full开启全量检查，并配合--show-leak-kinds=all区分definitely lost与still reachable。
编译时必须加 -g，否则看不到泄漏位置
Valgrind 本身不分析源码，它靠调试符号把内存分配地址映射回文件和行号。没加 -g 编译，输出里只会显示 vg_replace_malloc.c 这类内部路径，根本找不到你代码里哪一行调了 malloc 却没配 free。
正确编译命令是：
gcc -g -O0 -Wall leak.c -o leak
-O0 很关键：开优化后，编译器可能把未使用的指针直接删掉，导致 Valgrind 报 definitely lost 却找不到变量名；-Wall 能提前发现隐式类型转换、未使用变量等易引发泄漏的写法。
--leak-check=full 是定位泄漏的最低要求
默认的 --leak-check=summary 只告诉你“漏了 40 字节”，但不告诉你从哪来。必须显式加 --leak-check=full，Valgrind 才会打印完整的调用栈，例如：
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==12345== at 0x4846828: malloc (vg_replace_malloc.c:381) ==12345== by 0x1092AB: main (leak.c:5)
这里 leak.c:5 就是问题所在——你得去这行检查是不是漏了 free(ptr)。
常见疏忽点：
- 条件分支里只在
if分支free，else分支没处理 - 函数提前
return，跳过了后面的free - 指针被赋值为
NULL或新地址，原地址丢失
区分 definitely lost 和 still reachable
Valgrind 输出里这两类最常被混淆：
definitely lost：内存已完全失控，没有任何指针能访问到它——这是真泄漏，必须修复。
still reachable：程序退出时，指针还有效（比如全局变量、main 里定义的局部指针），内存 technically 没丢，但通常意味着你忘了在合适时机释放——尤其对长期运行的服务程序，这类“暂时安全”的内存会越积越多。
想一次性看到全部，加参数：--show-leak-kinds=all。别只盯着 definitely lost 忽略 still reachable 的累积效应。
实际运行命令别省略关键参数
单靠 valgrind ./a.out 几乎没用——它默认不检查泄漏，也不输出细节。稳定可用的最小命令是：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./leak
如果还怀疑有未初始化内存干扰判断，再加 --track-origins=yes，但注意它会让运行变慢一倍以上。
最后提醒一句：Valgrind 检测的是运行时行为。如果某段分配内存的代码根本没执行（比如分支没走到、测试数据太简单），它就查不到——得确保测试路径覆盖了所有 malloc 调用点。
