Valgrind能捕获悬空指针的使用行为（如释放后解引用），但仅在实际读写已释放内存时报错，无法主动标记指针是否悬空；必须用-g编译才能精确定位源码行，且-O0禁用优化以防编译器消除问题代码。
Valgrind 能直接捕获悬空指针的“使用”行为（如释放后解引用），但无法主动标记“当前指针是否已悬空”——它只在你真正读/写那块已被释放的内存时才报错。
valgrind --tool=memcheck 必须加 -g 编译才能准确定位行号
没带 -g 编译的二进制，Valgrind 只能报告“地址 0x... 上发生 use-after-free”，但不会高亮源码行。实际排查时几乎等于盲跑。
- 正确编译命令：
g++ -g -O0 -Wall crash_case_7.cpp -o crash_case_7 -
-O0关键：开启优化后，编译器可能把delete ptr和后续*ptr合并或删掉，导致 Valgrind 根本看不到问题 - CLion 用户注意：Run → Edit Configurations → CMake → Environment 中勾选
ENABLE_ADDRESS_SANITIZER是 ASan 路径，不是 Valgrind；Valgrind 需走 Tools → Valgrind → Run with Valgrind 单独启动
常见误判：valgrind 报 heap-use-after-free 却找不到 delete 或 free
这往往说明悬空来源不是显式 free/delete，而是更隐蔽的生命周期结束：
- std::vector 调用
resize()或clear()后，之前用data()拿到的指针立即失效 - lambda 捕获了局部变量地址（
[&local_var]{ ... }），函数返回后 local_var 销毁，指针悬空 - 返回局部对象的引用或指针（例如
return &local_str;），Valgrind 会报Address 0x... is on thread stack+Invalid read of size X - 多线程中一个线程
delete了对象，另一线程还在用其指针——Valgrind 默认单线程检测，这种竞态需配合--tool=helgrind
valgrind 输出里关键字段怎么看
一次典型的悬空访问输出中，以下三行决定你能不能快速修 bug：
-
Invalid read of size 4：说明是读操作（*ptr），size 是字节数（int 就是 4） -
at 0x...: main (crash_case_7.cpp:7)：出问题的源码行，注意是“访问发生处”，不是“释放发生处” -
by 0x...: main (crash_case_7.cpp:5)：前面的delete ptr行，Valgrind 会反向追溯分配/释放栈
如果没看到第二条“释放栈”，大概率是栈上悬空（比如返回局部变量地址），此时错误类型会变成 Address is on thread stack，而非 heap-use-after-free。
和 AddressSanitizer 对比时别混用场景
Valgrind 的 memcheck 在 Linux/macOS 下能抓到未初始化内存读取、系统调用级非法访问，但对栈悬空支持弱；ASan 启动快、精度到字节，但不支持未初始化值追踪，且 Windows 上需 Clang+MSVC 工具链。
- 查
double free或malloc/free 不配对：优先用 Valgrind +--leak-check=full --show-leak-kinds=all - 查
delete ptr后立刻*ptr：ASan 响应更快、报错更贴近源码逻辑 - 查
memcpy(buf, src, 100)但buf只有 10 字节：ASan 的越界检测更敏感；Valgrind 可能只报Invalid write，不提示具体越多少
真实项目里别只依赖一种工具——Valgrind 报告里那个 “still reachable” 内存块，有时恰恰是悬空指针正在悄悄持有的残留引用，得人工顺着指针链往回翻生命周期管理逻辑。
