valgrind 定位错误需编译时加 -g 且禁用优化（-o0），否则仅显示地址无行号；--track-origins=yes 才能追踪未初始化值源头；definitely lost 是唯一需修复的内存泄漏；invalid read/write 后的地址描述揭示越界或 use-after-free 关键信息。
编译时必须加 -g，否则报告里全是地址没有行号
Valgrind 报告要定位到具体哪一行代码出错，依赖调试符号。不加 -g 编译，valgrind --tool=memcheck 仍能运行，但所有错误堆栈只显示类似 0x402B06C: free 这样的地址，无法对应源码行——等于白跑。
实操建议：
-
gcc -g -O0 your.c -o your：务必同时用-O0关闭优化，否则变量被内联、函数被折叠，-g生成的调试信息会失效或错位 - 如果用
g++，同样加-g -O0；C++ 中尤其要注意new/delete匹配问题，没符号就看不到是哪行new没配delete - 避免混用
-g和-O2：常见坑是本地测试加了-g，但 CI 流水线用的是带优化的构建，结果 Valgrind 报告和实际代码对不上
--track-origins=yes 是查未初始化内存的唯一靠谱方式
像 int x; return x; 这类未初始化值传播问题，Valgrind 默认不追踪源头，只会报 “Use of uninitialised value”，但不说这个值最早从哪来。加了 --track-origins=yes 才能一路追到声明/读取点。
注意点：
- 该选项显著拖慢运行速度（可能慢 2–3 倍），仅在怀疑未初始化问题时启用，日常 leak-check 不必加
- 它对栈上变量和堆上内存都有效，但要求编译时有
-g，否则源头位置仍是问号 - 配合
--leak-check=full一起用时，报告会变长，重点看 “by” 后面的调用链，第一层通常是问题发生点，往上才是起源
报告里看到 definitely lost 就代表真实泄漏，别信 possibly lost
Valgrind 分四类泄漏：definitely lost、indirectly lost、possibly lost、still reachable。其中只有 definitely lost 是确定的、必须修复的泄漏——指指针彻底丢失，再无任何路径可访问那块内存。
常见误解：
-
possibly lost多半是误报，尤其出现在使用了libstdc++容器或第三方库时，它们内部可能用mmap或自管理内存池，Valgrind 跟踪不到 -
still reachable是正常现象，比如全局std::string或单例对象占的内存，进程退出前还没释放，但程序逻辑上没问题 - 真正要盯死的是
definitely lost行末标注的 “at 0x...: your_function (your.cpp:42)”——这行就是泄漏源头
别忽略 Invalid read/write 报告里的 Address 0x... 后缀
这类错误后面常跟一句类似 Address 0x4a2a2a2a is 10 bytes after a block of size 100 alloc'd 的说明，它比错误类型本身更有价值。
关键看两点：
- “is X bytes before/after a block”：直接告诉你越界偏移量，结合源码数组定义就能反推出下标错在哪（比如
arr[10]访问了 100 字节分配的arr[9]） - “alloc'd at” 和 “free'd at” 行：能确认是不是 use-after-free——如果某地址先被
free，后面又read，这两行会明确写出两次调用位置 - 注意
Address ... is in the Text segment这种提示：说明你传给free的根本不是堆地址（比如写了free(func_ptr)或free(&local_var)），属于严重误用
possibly lost 和第三方库路径，再逐条对照 definitely lost 和 Invalid 行末的地址描述——那里藏着最直白的线索。
