只关注“definitely lost”类泄漏的命令是：valgrind --leak-check=full --show-leak-kinds=definite ./myapp。必须使用definite（非definitely），且需配合--leak-check=full才能显示完整调用栈，否则无法精确定位泄漏源头。
只关注“definitely lost”类泄漏的命令写法
Valgrind 默认会报告四类泄漏（definitely lost、indirectly lost、possibly lost、still reachable），但真正需要立即修复的，只有 definitely lost——它代表堆内存已完全失去所有指针引用，100%无法回收。
要过滤掉其他三类、只看确定泄漏，关键不是靠后期 grep，而是从参数层面压制非关键输出：
- 使用
--show-leak-kinds=definite（注意拼写是definite，不是definitely） - 必须同时禁用
--track-origins=yes（它会强制开启更多上下文，干扰分类逻辑） - 避免
--leak-check=summary或默认值，它仍会混入其他类别摘要；坚持用--leak-check=full配合--show-leak-kinds
完整命令示例：valgrind --leak-check=full --show-leak-kinds=definite --verbose ./myapp
为什么 possibly lost 不能直接忽略
possibly lost 看似“可能”，但在 C++ 中常由真实问题触发：比如局部 std::vector 持有裸指针后被移动，或 RAII 对象析构顺序异常导致指针悬空。Valgrind 把这类“还能通过栈上残留地址访问到，但逻辑上已不该存在”的内存标为 possibly lost。
它不等于误报，尤其在以下场景中大概率是真问题：
- 代码含
setjmp/longjmp，破坏了栈帧与指针生命周期关系 - 使用了
std::shared_ptr循环引用（此时definitely lost反而不会出现，因为引用计数没归零） - 手动管理对象池，且释放逻辑未覆盖所有分支
所以，若你只想盯死 definitely lost，务必确认项目里没有上述模式——否则会漏掉关键泄漏点。
--show-leak-kinds 的合法取值和组合陷阱
--show-leak-kinds 接受多个值，用逗号分隔，但大小写敏感、无空格，且不支持通配符。常见错误包括：
-
--show-leak-kinds=definitely→ 错误：Valgrind 不识别该拼写，静默降级为默认行为 -
--show-leak-kinds=all→ 正确，但会包含still reachable（如全局缓存），干扰聚焦 -
--show-leak-kinds=definite,possible→ 合法，但possible是简写，对应possibly lost - 漏掉
--leak-check=full→ 即使指定definite，若用--leak-check=summary，仍只输出汇总行，看不到调用栈
最稳妥的最小集是：valgrind --leak-check=full --show-leak-kinds=definite ./myapp 2>&1 | grep -A 10 "definitely lost"
调试符号缺失时，“definitely lost”位置信息不可信
当编译未加 -g，Valgrind 仍能标记 definitely lost，但调用栈会退化成类似：at 0x4846828: malloc (vg_replace_malloc.c:381)by 0x1092AB: ??? (in /path/to/myapp)
此时 definitely lost 的判定本身有效，但你无法定位到哪一行代码分配的。修复方法只有两个：
- 重新用
gcc -g -O0或g++ -g -O0编译目标程序 - 若无法重编，可用
addr2line -e ./myapp 0x1092AB手动解析地址（需确保未 strip）
没有调试符号的 definitely lost 报告，只能告诉你“有”，不能告诉你“在哪”——这是最容易被忽略的盲区。
