Memcheck能精准检测五类典型内存错误：未初始化值使用、非法读/写、无效释放、memcpy重叠、内存泄漏；但不覆盖栈越界、静态变量未初始化、释放后仅比较、多线程竞态及内存碎片等问题。
Valgrind Memcheck 能直接抓到的五类典型问题
它不是万能的，但对以下五种 C/C++ 中高频、隐蔽、后果严重的内存错误，Memcheck 几乎总能稳准狠地报出来：
-
Use of uninitialised value(s)：比如局部指针未赋值就解引用、malloc后没初始化就直接读取 -
Invalid read/write：访问malloc(10)分配的内存后第 11 字节，或读写已free掉的地址 -
Invalid free：对同一块内存调用两次free，或用free释放new出来的指针 -
Source and destination overlap in memcpy：memcpy(dst, src, n)中dst和src地址重叠且非memmove -
definitely lost/possibly lost：程序退出时仍有堆内存没被free或delete，且无任何有效指针指向它
它查不到、或容易漏掉的几类情况
别指望它覆盖所有边界场景。这些是常见盲区：
- 栈上数组越界（如
char buf[4]; buf[5] = 0;）——Memcheck 默认不监控栈溢出，需配合--tool=exp-sgcheck（已废弃）或改用 AddressSanitizer - 静态/全局变量未初始化读取（如
static int x; printf("%d", x);）——这类未定义行为它不报告 - 释放后仅用于比较（如
if (p == nullptr)），不触发读写——不会报Use-after-free - 多线程竞态本身（如两个线程同时改同一变量）——这是
helgrind或drd的职责，Memcheck 不管 - 内存碎片或长期低效分配——它不统计碎片率，
massif才干这事
为什么有些“泄漏”它不报？关键看指针是否还活着
Memcheck 判断“泄漏”的逻辑很实在：只看程序结束时，有没有**活着的指针**指向某块已分配但未释放的内存。
- 如果指针被设为
nullptr，但内存没free→ 报definitely lost - 如果指针还在栈上、但作用域已退出（如函数返回后栈帧销毁）→ 报
possibly lost - 如果指针被存进全局容器（如
std::vector）但忘了清理 → 它认为“还有指针”，不报泄漏 - 如果指针被强制转成整数再转回（
uintptr_t i = (uintptr_t)p; p = (char*)i;）→ 可能逃过追踪，尤其没开--track-origins=yes
实际运行时必须加的编译和命令选项
跳过这步，90% 的问题它都定位不到源码行号，或者干脆不报。
- 编译时一定要带
-g：否则报错只显示???，看不到main.cpp:42 - 推荐启用
--leak-check=full：默认只报严重泄漏，full才会列出所有疑似泄漏块和调用栈 - 怀疑未初始化来源时加
--track-origins=yes：能指出那个uninitialised value是从哪一行传过来的，但性能下降明显 - 避免误报干扰，可用
--suppressions=mysupp.supp把已知第三方库问题屏蔽掉 - 别用
--tool=memcheck显式指定——它是默认工具，多写反而容易手误打错成--tool=memchek
真正难的从来不是“怎么跑 Valgrind”，而是读懂它报的每一行堆栈、区分 still reachable 和 definitely lost 的语义差异，以及确认那个 Invalid read 是真 bug 还是跨线程时序导致的假阳性。这些细节不翻源码、不结合调试器，光靠日志很难闭环。
