必须加-g且禁用优化，否则valgrind报错无行号或错乱；-g提供调试信息定位源码行，-o0防止优化导致代码重排、内联破坏行号映射。
编译必须加 -g，否则行号是空的
Valgrind 报错里显示的 main.cpp:19 这类位置信息，完全依赖编译时是否带 -g。不加 -g，所有报错只会显示函数名或地址，比如 by 0x8048444: main，根本没法定位到源码哪一行。
常见错误现象：
- 报错里只有
at 0x...: some_function，没有文件名和行号 - 行号对不上（比如显示第 5 行，实际出问题的是第 7 行）——这通常是用了
-O1或更高优化级
实操建议：
- 务必用
gcc -g -O0 -o myapp myapp.c编译，-O0最稳妥；-O1可能导致行号偏移，慎用 - 如果项目必须用
-O2构建发布版，调试阶段请单独用-g -O0编一个 debug 版本跑 Valgrind - C++ 项目同理，
g++ -g -O0，别信“带符号就行”，优化会重排代码、内联函数，直接破坏行号映射
--track-origins=yes 能补上未初始化值的源头行号
普通报错如 Invalid write of size 4 通常能直接给出出错行，但像 Conditional jump or move depends on uninitialised value(s) 这类，只告诉你“用了未初始化值”，却不告诉你这个值最初从哪来——这时候默认输出里往往只显示判断语句那行，不是赋值那行。
实操建议：
- 遇到未初始化相关报错，立刻加
--track-origins=yes重跑：valgrind --tool=memcheck --track-origins=yes ./myapp - 它会多输出一层 “by … allocated at …” 或 “originated at …”，精准指向变量首次声明/读取/传参的位置
- 代价是运行速度再降 2–3 倍，但值得——没它，你可能在几十行里盲猜哪个
int x;没初始化
报错里的 Address 0x... is 0 bytes after a block of size 40 alloc'd 暗示分配点行号
越界类错误（Invalid read/write）的报错分两块：出错点 + 分配点。后者那行 alloc'd 很关键，它告诉你内存是在哪申请的，往往比出错行更接近根因。
例如：
==1234== Invalid write of size 4 ==1234== at 0x804838F: f (test.c:5) ==1234== by 0x80483AB: main (test.c:10) ==1234== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd ==1234== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) ==1234== by 0x8048385: f (test.c:4)
这里 test.c:4 是 malloc(10*sizeof(int)) 的位置，test.c:5 是越界写 x[10] 的位置。两个都得看：分配太小？索引算错？还是两者都有？
注意点：
- 如果
alloc'd行显示的是系统库（如libc或libstdc++），说明问题出在封装层，得往调用栈上翻，找你自己的函数那一层 - 动态库中分配的内存，若没带调试信息，
alloc'd行可能只显示地址，这时得结合-g编译你自己的模块，并确保动态库也带符号
泄漏报告里的 definitely lost 行号有时藏在间接调用里
LEAK SUMMARY 显示 definitely lost 后跟的堆栈，第一行常是 malloc 或 new，但第二行才是你的代码——而这一行未必是你写 malloc 的地方，可能是封装函数。
比如：
==1234== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==1234== at 0x4C2B0E0: malloc (vg_replace_malloc.c:381) ==1234== by 0x1092AB: create_string_set_from_file (spellcheck.c:25) ==1234== by 0x1093CD: main (spellcheck.c:89)
真正该改的不是 spellcheck.c:25（那里只是封装了 malloc），而是检查 create_string_set_from_file 的调用者有没有配对释放，或者这个函数内部有没有漏掉 free。
容易被忽略的地方：
- 报错行号指向的是分配点，不是泄漏点——泄漏点是你忘了
free的那个作用域，可能在另一个文件、另一个函数里 - 如果用了智能指针或 RAII，Valgrind 仍会报
definitely lost，说明对象生命周期管理失效（比如裸指针逃逸、循环引用没破），不能只盯着 malloc 行 -
still reachable通常不用修，但如果你看到大量这种，说明程序退出前还有活跃指针，可能掩盖了真正的泄漏
