“invalid free”或“double free”表明程序非法释放内存，如释放栈变量、已释放指针或null；valgrind可精确定位错误行及调用栈，常见原因包括重复释放、误释栈内存、释放字面量等。
程序退出时报告“Invalid free”或“double free”
这类提示说明你在 free() 一个非法地址，比如栈上变量、全局数组、NULL 指针，或者已经 free() 过的指针。Valgrind 会直接在错误行标出 Invalid free() / delete / delete[]，并给出调用栈。
常见诱因包括：
-
char buf[1024]; free(buf);—— 栈变量不能free -
int *p = malloc(4); free(p); free(p);—— 重复释放 -
int *p = NULL; free(p);—— 虽然 C 标准允许free(NULL)，但某些旧版 Valgrind（尤其带--workaround-gcc296-bugs=yes时）可能误报，建议先确认是否真有非空指针被重复释放 - 把函数返回的字符串字面量（如
"hello"）当成堆内存去free
定位方法：看报告中 by 0x...: main (xxx.c:LINE) 那一行，直接跳转到对应源码行检查释放对象来源。
退出时看到“definitely lost”但程序没崩溃
这不代表程序会立即崩，而是说进程退出前仍有堆内存未被 free()，且没有任何活跃指针指向它——即泄漏已发生，只是当前没触发副作用。
关键要看报告末尾的 LEAK SUMMARY 区域：
-
definitely lost：必须修复，是真实泄漏 -
indirectly lost：由definitely lost块所引用的其他块，顺带一起泄漏 -
possibly lost：指针可能还在栈/寄存器里，但 Valgrind 不确定是否还能访问，需人工判断 -
still reachable：内存没被释放，但至少还有一个有效指针能触达它（比如全局指针、static 变量），通常不是 bug，除非你明确期望它被释放
别只看总量，重点查 definitely lost 对应的 at ... by ... (file.c:line) —— 那就是 malloc() 发生的位置，逆向追踪为什么没配对 free()。
退出时没报错，但程序实际崩溃了
Valgrind 报告 “ERROR SUMMARY: 0 errors” 并不等于安全。它只检测 memcheck 覆盖的内存类问题，而以下情况 Valgrind 默认不捕获：
- 栈上越界读写（如
char a[8]; a[10] = 1;）—— 不报错，但可能破坏栈帧导致后续ret崩溃 - 未定义行为（UB）：整数溢出、除零、
signed位移越界等 - 信号处理异常（如
kill -SEGV强制终止） - 多线程竞争（需换用
--tool=helgrind或--tool=drd）
如果程序在 Valgrind 下运行正常，但原生运行崩溃，优先怀疑：栈破坏 或 未初始化变量参与关键逻辑分支。此时加 --track-origins=yes 再跑一次，看是否有 Use of uninitialised value 提示。
log 文件里一堆 “suppressed” 信息干扰判断
Valgrind 启动时会加载系统库的 suppressions 规则（比如 glibc 内部的 malloc 实现细节），这些被压制的报告本意是减少噪音，但有时会掩盖你自己的问题。
排查建议：
- 加
--gen-suppressions=all重新运行，Valgrind 会把所有压制项以 suppressions 格式打印到 stdout 或 log，你可以从中识别哪些是你的代码触发却被误压的 - 用
--suppressions=my.supp显式指定你认可的压制规则，避免默认规则过度干预 - 对比两次运行：一次不加任何 suppression 参数，一次加
--suppressions=none，观察错误数量是否突增——若突增，说明默认压制掩盖了问题
真正难搞的往往不是满屏报错，而是“看起来没问题却崩得莫名其妙”的情况：栈越界、未初始化值传播、跨线程裸指针共享——这些都需要结合 --track-origins=yes、--tool=helgrind 或 GDB 交叉验证。
