能，但需异常分支实际执行；valgrind memcheck 是运行时工具，仅记录真实发生的内存操作，未执行的释放会导致“definitely lost”泄漏报告。
Valgrind 能否检测“异常分支没释放资源”？
能，但前提是异常分支实际被执行了。Valgrind 的 memcheck 是运行时检测工具，它不分析控制流逻辑，只记录真实发生的内存分配与释放行为。如果某条 if 分支、else 块或 catch 块在本次运行中没走到，里面的 free 或 delete 就不会执行，Valgrind 就会把对应分配的内存标为“definitely lost”。
为什么只跑一次 main 通常不够？
多数内存泄漏被漏掉，是因为测试只覆盖了“正常路径”。比如：
- 函数里
malloc后，if (error) { free(p); return -1; }写了，但测试时error永远为假，free实际没触发 - C++ 中
new后抛出异常，但没写try/catch或没在析构里清理，异常路径跳过释放逻辑 - 多路
return中只有一处写了free，其余返回点遗漏
Valgrind 报告的 “definitely lost” 行号，往往就是那个“只在某些条件下才该执行、但这次没执行”的释放语句的上一行——也就是分配位置。
怎样让 Valgrind 暴露这类问题？
关键不是改 Valgrind 参数，而是**让异常分支真正运行起来**。实操建议如下：
- 对 C 程序：用预处理器宏或环境变量临时强制触发错误路径，例如
#ifdef FORCE_ERROR_PATH包住if (1) { ... } - 对 C++ 程序：在可能抛异常的位置前加
throw std::runtime_error("test");，或用__attribute__((no_sanitize("address")))配合 ASan 更快验证（但 Valgrind 仍需实际跑） - 编译时务必带
-g，否则 Valgrind 输出只有地址，看不到foo.c:42这类线索 - 别依赖
--leak-check=summary，必须用--leak-check=full --show-leak-kinds=all，否则间接泄漏（indirectly lost）可能被忽略
常见误判和干扰项
Valgrind 不会把“没走的分支”直接标为 bug，但它给出的泄漏报告会暴露设计盲区。容易混淆的情况包括：
-
reachable类型泄漏：内存还被某个全局指针持有，看似“没泄漏”，实则是资源未显式归还，后续可能堆积 - 第三方库内部缓存（如 glibc 的
mallocarena）导致的still reachable，和你的分支逻辑无关，需结合调用栈过滤 - C++ RAII 对象没析构（比如忘了写
~MyClass() { delete p_; }），Valgrind 会报definitely lost在new行，而非析构函数里——因为析构根本没调用
真正难定位的，永远是那些只在特定输入、特定系统状态（如 fork() 失败、open() 返回 -1）下才触发的释放缺失。Valgrind 能告诉你“这里漏了”，但不能替你补全所有 error path —— 它只是把代码里没被执行的防御性释放，赤裸地摆到你面前。
