必须加 -g 编译，否则 valgrind 无法显示泄漏代码行号；需配合 -o0、--leak-check=full、--show-leak-kinds=all 和 --num-callers=20，并沿堆栈向上定位首个用户函数。
必须加 -g 编译，否则堆栈全是问号
Valgrind 要显示具体哪一行代码分配了泄漏内存，依赖调试符号。没加 -g 编译的二进制文件，valgrind 只能打出函数名（甚至只是地址），行号全丢。这不是 Valgrind 的限制，是编译器没留下信息。
实操建议：
- 用
gcc -g -O0或g++ -g -O0重新编译，禁用优化（-O0）避免内联和指令重排干扰堆栈回溯 - 确认符号存在：
file ./your_program输出里要有with debug_info；或者nm -C ./your_program | grep main能看到带源文件名的符号 - 如果程序由 CMake 构建，确保
CMAKE_BUILD_TYPE是Debug，且未手动覆盖CMAKE_CXX_FLAGS把-g删掉
--leak-check=full 和 --show-leak-kinds=all 缺一不可
只开 --leak-check=full 默认只报 definitely lost，但很多泄漏实际属于 indirectly lost（比如对象 A 持有指针指向 B，A 泄漏导致 B 连带泄漏）或 possibly lost（指针可能被移位或计算偏移后丢失）。不显式加 --show-leak-kinds=all，这些都不会出现在报告里。
关键参数组合：
-
--leak-check=full：启用完整泄漏检测（含堆栈、大小、分配点） -
--show-leak-kinds=all：强制显示definitely/indirectly/possibly三类 -
--num-callers=20：默认只打 12 层调用，复杂模板或封装深的 C++ 代码容易截断，拉到 20 更稳妥
泄漏点不是 new 行，而是它上一级调用者
Valgrind 显示的“allocated at”位置，是 malloc / operator new 的直接调用点——但这个调用往往在 STL 或框架内部（比如 std::vector::push_back 内部调用 realloc）。真正该修的代码，是你调用了那个容器或 API 的地方。
识别真实源头的方法：
- 顺着堆栈往上翻，找第一个你写的函数名（不是
std::或libc开头的） - 注意
in .../your_file.cpp:142这类标记，142 行大概率是容器操作、工厂函数或资源加载逻辑 - 如果堆栈里全是
???，说明对应 so 文件没带调试符号，需检查是否链接了 debug 版本的第三方库（如libboost_system.so.1.85.0对应的libboost_system.so.1.85.0.debug）
--track-origins=yes 对“未初始化值”有用，对泄漏定位帮助有限
这个参数主要解决 Use of uninitialised value 类错误，它会追溯变量第一次被读取时的赋值来源。但它不参与泄漏分析流程——泄漏判定靠的是“退出时还有多少块 malloc 返回的指针没被 free”，和值是否初始化无关。
所以：
- 查泄漏时不用加
--track-origins=yes，徒增运行开销（慢 2–3 倍） - 如果你同时看到泄漏 + “invalid read of size X”，再考虑加上它，分开两次跑更清晰
- 真要定位“谁把指针弄丢了”，得靠堆栈里你自己的函数名 + 静态分析（比如搜索所有对该类型指针的赋值/传参/返回）
最常被忽略的一点：Valgrind 报告里的“still reachable”内存，不是 bug，但可能是设计缺陷——比如全局缓存、单例对象持有的资源，它们在 main 结束前没释放，但程序生命周期内一直有效。别急着去“修复”，先确认这是否符合预期。
