Valgrind Memcheck能直接检测use-after-free，原理是跟踪堆内存的分配与释放状态；启用--track-origins=yes可追溯野指针来源，但仅限malloc/new分配的堆内存，不监控栈或全局变量。
用 Valgrind 的 Memcheck 检测 use-after-free 最直接
Valgrind 本身不区分“C++ 对象”和普通内存，它只跟踪堆上 malloc/new 分配、free/delete 释放的内存块。只要你在 delete 后还读写该指针指向的地址，Memcheck 就能捕获——前提是程序没崩溃退出太快，且你启用了对应检测选项。
关键不是加什么 C++ 特殊开关，而是确保：
- 编译时带 -g（保留调试信息）
- 链接时不 strip 符号
- 运行时用 valgrind --tool=memcheck --track-origins=yes ./your_program--track-origins=yes 很重要：它能告诉你那个野指针最初是从哪次 new 来的、在哪被 delete 掉的，否则你只能看到“invalid read”，但找不到源头。
为什么有时候 Valgrind 报了 use-after-free 却找不到对应 delete？
常见原因有三个：
- 对象在栈上或全局区，Valgrind 不管这些——它只盯堆内存；你看到的“use-after-free”一定发生在堆上，比如
std::vector内部缓冲区、new出来的对象、std::string的堆分配数据等 - 用了 placement
new但手动调了operator delete，而 Valgrind 没法关联构造/析构语义，只认malloc/free级别操作 - 多线程下释放和访问时间差极小，Valgrind 的插桩可能漏掉某次访问，或者报错位置离实际出问题的代码行偏移几行（尤其开了优化后）
std::shared_ptr 或 unique_ptr 释放后访问，Valgrind 能抓到吗？
能，但条件苛刻：
如果智能指针管理的对象是堆分配的（绝大多数情况），那么底层仍走 new/delete，Valgrind 照常检测。但注意两点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
std::shared_ptr的控制块（control block）和托管对象是分开分配的，Valgrind 只会报托管对象的 use-after-free，不会报控制块的——除非你手撕控制块 - 如果你把
shared_ptr的裸指针存下来（比如int* p = sp.get()），然后在sp析构后用p，Valgrind 一定能报；但如果你只是反复拷贝shared_ptr，它自己管理生命周期，就不会触发 use-after-free
简单说：Valgrind 不懂智能指针语义，它只看最终那块堆内存有没有被 free 后再访问。
比 Valgrind 更快定位 C++ 对象 use-after-free 的替代方案
Valgrind 精确但慢（10–30 倍 slowdown），日常开发中可先用更轻量的工具缩小范围：
- AddressSanitizer（
-fsanitize=address）：编译期插桩，开销小（2×），报错精准到行+变量名，还能显示堆栈和释放点；Clang/GCC 都支持，是目前最推荐的首选 - UBSan（
-fsanitize=undefined）：对某些特定场景（如delete后取sizeof）有额外检查，但不如 ASan 全面 - Valgrind +
--freelist-vol=100000000：增大空闲内存池，避免因内存复用太快导致 use-after-free 漏报（默认只缓存 1MB）
ASan 报的 heap-use-after-free 错误信息里，会明确标出 freed by thread T0 here: 和 allocated by thread T0 here:，比 Valgrind 的 Invalid read of size X 更直白。真要深挖 Valgrind 日志，得习惯看 “Address 0x… is 8 bytes inside a block of size 16 free’d” 这类提示——那个 “8 bytes inside” 就是你访问的偏移，结合源码才能确认是不是对象成员。
