Valgrind查内存泄漏核心三步：编译加-g和-O0、运行用--leak-check=full --show-leak-kinds=all --track-origins=yes --verbose、重点区分definitely/indirectly/possibly lost及still reachable四类泄漏。
直接用 Valgrind 查内存泄漏，核心就三步：编译带调试信息、运行时加关键参数、看懂报告分类。它不是“一跑就出答案”的黑盒，而是需要你配合理解业务逻辑的证据工具。
编译程序时必须加 -g
Valgrind 不修改源码也不依赖编译器插桩（比如 ASan），但它靠符号信息定位行号。没 -g 就只能看到汇编地址或函数名，根本没法修。
- 推荐编译命令：
gcc -g -O0 leak.c -o leak - -O0 是为了防止编译器优化掉可疑代码路径，让检测更可靠
- 不用改源码，也不用链接特殊库，纯运行时检测
运行时用这组参数组合最实用
单靠 --leak-check=full 往往漏掉关键线索。建议一次带上四类信息：
-
--leak-check=full：展开每处泄漏的完整调用栈 -
--show-leak-kinds=all：不只看 definitely lost，also show indirectly lost、possibly lost 和 still reachable -
--track-origins=yes：查未初始化内存来源（对“使用野指针”类问题极有用） -
--verbose：显示统计摘要和进程退出状态，方便判断是否真有泄漏
完整命令示例：valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose ./leak
重点看懂四类泄漏含义
Valgrind 把堆内存分四档归类，每一档对应不同修复优先级和排查思路：
- definitely lost：指针彻底丢了，malloc 后没存地址也没 free —— 这是典型真泄漏，优先修复
- indirectly lost：因为上面那个 definitely lost 的对象里还存着其他指针，连带导致它们也找不到了
- possibly lost：指针可能还在栈或寄存器里，但 Valgrind 没追踪到明确引用路径 —— 需人工确认是否真丢
- still reachable：指针还在全局变量、静态变量或当前栈帧里 —— 不算 bug，但可能是缓存堆积、日志队列不清理等逻辑问题
别忘了输出重定向和抑制误报
实际项目中报告太长，建议把结果存文件：valgrind --log-file=valgrind-out.txt [其他参数] ./myapp
- 加
--gen-suppressions=all可生成 suppressions 规则，把已知第三方库或无害行为标记为忽略 - 若程序带子进程，加
--trace-children=yes才能穿透检测 - 遇到多线程竞争，可额外启用
helgrind工具单独分析
