Valgrind Memcheck 能精准定位6类高危内存错误：“definitely lost”和“Invalid read/write”须立即处理；内存泄漏仅标记退出时不可达的堆块；非法访问是崩溃前兆；未初始化值导致逻辑错乱；堆操作不匹配破坏内存管理；其余异常需结合其他工具验证。
Valgrind Memcheck 能直接定位到 6 类最危险的内存错误，其中“definitely lost”和“Invalid read/write”是必须立刻处理的硬性问题。
内存泄漏（definitely lost / possibly lost）
不是所有“没 free”的代码都算泄漏——Memcheck 只标记那些退出时仍被指针持有、且无法通过任何路径访问到的堆块为 definitely lost。possibly lost 通常出现在指针被强制类型转换或存入结构体字段后丢失了原始类型信息的情况。
常见诱因：
• malloc 后只保存了偏移地址（如 p + 4），原指针丢失
• 全局/静态指针在多线程中被覆盖或清零
• C++ 中 new 分配后赋值给 std::shared_ptr 前发生异常，导致裸指针逸出
注意：--leak-check=full 才能显示调用栈，--show-leak-kinds=all 会额外报告 indirect 和 possible 泄漏，但后者常为误报。
非法内存访问（Invalid read / Invalid write）
这是崩溃的直接前兆，比泄漏更紧急。
典型现象：
• 程序运行时 SIGSEGV，但 gdb 显示地址合法（其实是已被 free）
• 数组下标越界读写，尤其在 malloc(n) 后访问 p[n] 或 p[-1]
• 使用 alloca 或 VLAs 分配的栈内存，在函数返回后继续访问
Memcheck 会明确指出访问大小（如 Invalid read of size 8）和地址状态（“is not stack'd, malloc'd or free'd” 表示野地址，“is 8 bytes inside a block of size 16 free'd” 表示 UAF）。
未初始化内存使用（Use of uninitialised value）
这类问题不一定会立即崩溃，但会导致逻辑错乱、随机结果甚至安全漏洞。
触发条件：
• 局部变量声明后未赋值就参与条件判断（if (flag)）或作为系统调用参数（write(fd, buf, len) 中 len 未初始化）
• malloc 返回内存未清零就直接读取（memset 漏掉或长度算错）
• 结构体部分字段未初始化，后续 memcpy 整体拷贝
加 --track-origins=yes 能定位未初始化值源头，但会让运行变慢 2–3 倍，调试时开，CI 中关。
堆操作不匹配（Mismatched free / delete）
看似小问题，实则破坏堆管理器内部链表，可能延迟数小时才暴露。
典型组合：
• new[] 配 delete（而非 delete[]）
• malloc 配 delete（C++ 中极常见）
• realloc 后对旧指针再次 free
Memcheck 会报 “Mismatched free() / delete / delete []”，并标注分配和释放点。注意：它不检查 aligned_alloc 与 free 的对齐兼容性，那是 AddressSanitizer 的范畴。
真正难缠的是那些不报错但行为异常的问题——比如 memcpy 中 src 和 dst 重叠、向 malloc 传负数 size、或栈溢出（Memcheck 不管栈空间，得靠 ulimit 或 gdb）。这些往往需要结合其他工具交叉验证，不能只盯 Valgrind 输出里的那几行 “definitely lost”。
