Valgrind的Memcheck能直接捕获use-after-free问题，无需插桩或特殊编译选项，仅需使用标准堆内存分配函数；首次非法读/写即报错中断，典型提示含“Invalid read/write”及释放与访问行号。
Valgrind 的 Memcheck 工具能直接捕获 use-after-free（释放后访问）问题，不需要额外插桩或编译选项，但必须保证程序用的是标准内存分配函数（malloc/free、new/delete 等），且未被自定义 allocator 替换。
运行时会立刻报错，不是等到退出才提示
和内存泄漏不同，use-after-free 是运行时非法行为，Memcheck 在第一次发生非法读/写时就中断并输出错误。典型报错形如：
==12345== Invalid read of size 4 ==12345== at 0x40118B: main (test.c:12) ==12345== Address 0x4a2c040 is 0 bytes inside a block of size 40 free'd ==12345== at 0x4846828: free (vg_replace_malloc.c:872) ==12345== by 0x40117E: main (test.c:9)
关键线索是 Invalid read/write + is ... inside a block of size ... free'd。它会明确指出：哪一行释放了内存，哪一行又去读/写了它。
- 只要触发，
valgrind默认会中止程序（可加--error-exitcode=1让脚本识别失败） - 不需要
--leak-check参数——这个错误跟泄漏无关，属于“非法访问”类 - 如果程序有 signal handler 捕获
SEGV并忽略，Memcheck仍能检测到，不会被绕过
为什么有时候没报？常见漏检原因
不是所有释放后访问都会被 Memcheck 抓住，以下情况容易静默跳过：
-
free后立即用同一指针赋值给另一个变量，但没做任何读/写操作（只是“悬空”，不触发检查） - 释放的是栈内存或全局内存（
Memcheck只监控堆内存：malloc/new分配的） - 使用了自定义分配器（如
jemalloc或重载了operator new却没用--soname-libjemalloc等适配） - 释放后访问的是已落入
freelist但尚未被复用的内存块——此时地址可能仍“可读”，Memcheck不报（这是设计使然，非 bug）
如何让 use-after-free 更容易暴露
默认行为已经足够敏感，但你可以加几个参数增强定位能力：
-
--track-origins=yes：如果报错是Conditional jump or move depends on uninitialised value(s)但怀疑源头是use-after-free，这个参数能帮你回溯到指针最初从哪来（性能下降明显，只在必要时开） -
--freelist-vol=100000000：增大free后内存块在 freelist 中保留时间，提高再次访问时被检测到的概率（单位字节，默认 20MB） -
-v：配合错误输出看更详细的上下文，比如是否涉及mmap区域、是否在dlmalloc内部等
真正难缠的 use-after-free 往往发生在多线程环境里：一个线程刚 free，另一个线程恰好拿到旧指针并访问——Memcheck 能抓到，但 Helgrind 才是专治这种竞态的工具。别指望单靠 Memcheck 覆盖全部场景。
