必须编译时加-g和-o0，否则valgrind无法显示源码行号；用--track-origins=yes定位内存来源，--leak-check=full --show-leak-kinds=all检测泄漏；未初始化值导致的条件判断错误需彻底初始化而非仅判空。
valgrind 报 Invalid read 或 Invalid write 怎么定位具体行号
默认情况下 valgrind 只显示汇编偏移或模糊的函数名，根本没法修。必须让编译器保留调试信息，并关闭优化——否则符号全被抹掉，valgrind 看不到源码行。
- 编译时加
-g（必需），不加就永远只能看到??? - 务必加
-O0；用-O2会导致变量被优化掉、代码重排，报错位置和实际不一致 - 如果用了
inline函数或宏，错误可能指向调用点而非真正出问题的内部，得结合--track-origins=yes看内存来源 - 运行命令示例：
valgrind --track-origins=yes ./a.out
检测堆内存泄漏必须用 --leak-check=full，但默认不生效
valgrind 默认只做基础检查，definitely lost 类泄漏不会自动报告——它把大部分泄漏归为 still reachable，看起来“没事”，其实只是没被 free。
- 必须显式启用：
valgrind --leak-check=full --show-leak-kinds=all ./a.out -
--show-leak-kinds可选值有definite、possible、reachable；生产环境建议至少用definite,possible - 注意：程序退出前未释放的全局指针、静态缓冲区会被标为
still reachable，这不是 bug，但容易误判——得看是否本该在 exit 前清理 - 如果程序是 daemon 或长期运行的，要手动触发退出路径，否则 valgrind 不会输出泄漏汇总
Conditional jump or move depends on uninitialised value(s) 的真实含义
这不是警告，是明确告诉你：某个 if 判断、for 条件、甚至 strlen() 的入参，依赖了未初始化的内存。C 标准里这是未定义行为，但 gcc 不报错，valgrind 是少数能稳定抓到它的工具。
- 常见场景：
char buf[256]; strcpy(dst, buf);——buf没初始化，strcpy会一直扫到随机的\0 - 结构体局部变量未用
= {0}或memset清零，后续取.flag字段判断就中招 -
malloc返回的内存不会清零，calloc才会；别以为malloc后直接用字段安全 - 修复方式不是加
== 0判断，而是确保初始化——否则改天换平台或编译器就崩
为什么在 CI 或远程服务器上跑 valgrind 经常卡住或报错
valgrind 本质是动态二进制插桩，对系统调用、信号、多线程非常敏感。不是所有环境都适合直接跑。
- 容器环境（Docker）默认禁用
ptrace，需加--cap-add=SYS_PTRACE启动容器 - 某些云主机内核禁用
perf_event_paranoid，导致 valgrind 无法读取性能寄存器，报Operation not permitted；临时修复：echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid - 多线程程序要加
--tool=helgrind或--tool=drd才能查竞态，但默认memcheck会忽略线程交互，漏掉关键问题 - 图形界面程序（如用 X11 的）可能因信号处理异常挂起，建议先用
--quiet --log-file=valgrind.log跑后台，避免阻塞
内存错误往往不在 crash 那一刻发生，而是在几轮分配/释放后才暴露。一次跑过不等于没问题，重点看 Invalid 和 uninitialised 这两类——它们才是真正在啃你程序根基的东西。
