必须加 -g 编译，否则 Valgrind 仅报地址无行号；应使用 -g -O0 而非 -O2 以避免优化干扰检测；务必启用 --leak-check=full 和 --track-origins=yes 定位根因。
编译时必须加 -g，否则 Valgrind 报错不带行号
Valgrind 本身不依赖源码，但它靠调试符号定位错误位置。没加 -g 编译的二进制，Valgrind 只能报出地址和汇编偏移，比如 at 0x400E16，根本没法对应到 C/C++ 行。加了 -g 后，它才能输出类似 main (myapp.c:42) 这种可读信息。
常见错误现象：运行 valgrind ./a.out 后看到一堆 ??? 或 in ???:??? —— 这基本就是漏了 -g。
- 正确做法：
gcc -g -o myapp myapp.c或g++ -g -o myapp myapp.cpp - 别信“反正能跑就行”——没有行号的报告等于废纸
- 如果项目用 CMake，确保
CMAKE_BUILD_TYPE是Debug，且未覆盖CMAKE_CXX_FLAGS清掉-g
-O0 不是可选，是强烈建议
开启优化（如 -O2）会让 GCC 重排、内联、删变量，导致 Valgrind 看到的执行流和源码不一致。比如一个 malloc 调用被优化掉，或指针被存进寄存器而非内存，--track-origins=yes 就失效；又或者越界访问被优化成无害行为，Valgrind 直接检测不到。
典型表现：同一段代码，-O2 下 Valgrind 没报错，-O0 下立刻爆出 Invalid read of size 4。
- 稳妥编译命令：
gcc -g -O0 -Wall -Wextra myapp.c -o myapp -
-Wall -Wextra能提前发现部分潜在问题，减少 Valgrind 后期负担 - 若必须测优化后行为，至少先用
-O0定位问题，修复后再验证-O2是否引入新问题
别跳过 --leak-check=full 和 --track-origins=yes
默认的 valgrind ./a.out 只开基础检查，漏掉大量关键信息。比如未初始化值只报“Use of uninitialised value”，但不说这个值从哪来；内存泄漏只说“definitely lost”，却不显示分配点调用栈。
这两个参数不是锦上添花，而是定位根因的刚需：
-
--leak-check=full让 Valgrind 在退出时打印每一块泄漏内存的完整分配路径，精确到malloc调用位置 -
--track-origins=yes配合未初始化警告，能回溯到变量首次声明/赋值处（哪怕跨函数），极大缩短排查链路 - 组合使用：
valgrind --tool=memcheck --leak-check=full --track-origins=yes --show-leak-kinds=all ./myapp
遇到 Syscall param write(buf) points to unaddressable byte(s) 别慌
这其实是 Valgrind 在帮你抓更底层的问题：你的程序传给 write()、send() 等系统调用的缓冲区，部分内容处于 invalid 状态（比如 malloc 后没填满、或 strcpy 截断导致尾部未初始化）。它不是误报，而是暴露了数据构造逻辑缺陷。
常见场景：
- 用
malloc(1024)分配缓冲区，只填了前 100 字节就传给write(fd, buf, 1024) - 结构体中有 padding 字段，
memset没清全，send()发送整个结构体 - 字符串操作后忘记补
'\0'，后续用strlen()或write()时越界
解决方法不是绕过检查，而是显式初始化或精确控制长度：用 memset 清零、用 snprintf 替代 sprintf、传参时用实际长度而非缓冲区大小。
indirectly lost）」——它不指向你直接 malloc 的那块内存，而是指向被泄漏对象所引用的其他内存。这种链式泄漏必须结合 --leak-check=full 的完整调用栈才能看清源头，单看 definitely lost 会漏掉真正的问题根节点。 
