valgrind 不直接检测异常路径，但能暴露未释放堆内存：异常导致跳过释放语句时，内存常被标记为“still reachable”；需用--show-leak-kinds=all和-track-origins=yes配合-g -o0编译定位问题，且它不监控非堆资源。
Valgrind 本身不直接“查异常路径”，但它能暴露所有未释放资源的最终结果——只要那段路径没调用 free、delete 或对应释放逻辑，Memcheck 就会把这块内存记为“still reachable”或“definitely lost”，无论它是否在 catch 块、goto 跳转、早期 return 或信号中断后遗漏。
为什么 --leak-check=full 看不到异常路径里的泄漏？
因为默认的 --leak-check=summary（或 =yes）只报告“确定泄漏”的块，而异常提前退出导致的资源残留，常被归类为 reachable：指指针还活着（比如局部变量还在栈上、全局指针仍指向它），只是程序逻辑没走到释放语句。这类泄漏 Valgrind 不报“leak”，但你得自己盯住。
-
--show-leak-kinds=all必须加，否则reachable类型完全不显示 -
--track-origins=yes能帮你回溯 malloc 是在哪一行分配的，尤其当指针被多次赋值后丢失原始上下文 - 如果用了 RAII（如
std::unique_ptr）但析构函数没被调用（比如异常抛出时跳过了作用域结束），Valgrind 依然会看到 raw pointer 指向的内存未释放——它不管 C++ 语义，只看malloc/new 调用和free/delete 是否成对
如何让异常路径的资源泄漏显形？
关键不是让 Valgrind “理解异常”，而是让它捕获所有未配对的分配。你需要确保：
- 编译时加
-g，否则连哪条new没被析构都定位不到 - 禁用优化（
-O0），否则编译器可能把未使用的指针优化掉，导致 Valgrind 认为内存“lost”而非“reachable” - 若程序用
setjmp/longjmp跳过析构，Valgrind 同样无感——它只监控 libc 内存函数，不插桩 C++ 栈展开逻辑 - 对 C++，避免裸指针 + 手动
new/delete；改用std::vector、std::string或智能指针，能让 Valgrind 报告更集中（比如只报new分配点，而不是每个malloc细节）
常见误判：reachable 不等于安全
输出里出现 16 bytes in 1 blocks are still reachable 很容易被当成“没问题”。但如果你的代码有如下结构：
void risky_func() {
int *p = new int[4];
if (some_condition) throw std::runtime_error("boom");
delete[] p; // 异常时这行根本不会执行
}
Valgrind 会标记这块内存为 still reachable（因为 p 是栈上局部变量，异常栈展开时它已销毁，但 new 出来的内存还在）。这不是 Valgrind 的缺陷，而是提醒你：C++ 异常安全不能靠“人肉检查路径”，得靠 RAII 或 try/catch 显式兜底。
真实调试中容易忽略的一点
Valgrind 不拦截 mmap、brk 等系统调用分配的内存，也不管文件描述符、socket、pthread mutex 这类非堆资源。所谓“异常路径没释放资源”，如果涉及这些，Valgrind 完全沉默——你得配合 lsof -p <pid></pid> 或 /proc/<pid>/fd/</pid> 手动核对。它只管堆内存的 malloc/free 和 new/delete 配对。
