Valgrind通过memcheck工具可检测malloc/new未配对free/delete、use-after-free、buffer overflow、uninitialized value等运行时内存错误；需-g -O0编译以准确定位，重点处理definitely lost和Invalid read/write，still reachable通常可忽略。

Valgrind能检测哪些内存问题

Valgrind本身不直接“检测内存泄漏”，它通过 memcheck 工具在程序运行时监控所有内存分配/释放行为，从而发现：malloc/new 后没配对 free/delete、访问已释放内存、越界读写、未初始化内存使用等。真正报告“definitely lost”或“still reachable”的，才是泄漏线索。

编译时必须加 -g 且避免优化

没有调试信息，Valgrind 只能显示汇编地址，无法定位到源码行；开启 -O2 或更高优化后，编译器可能把堆分配内联、合并甚至删掉，导致漏报或误报泄漏。实际操作中：

• 用 g++ -g -O0 -o myapp main.cpp 编译（-O0 显式关闭优化比不写更稳妥）
• 若链接了第三方静态库，确保它们也带 -g；否则对应栈帧会显示为 ???
• 不要用 -fomit-frame-pointer，它会让调用栈截断，影响泄漏溯源

运行 Valgrind 时的关键参数组合

默认只报严重错误，漏掉很多潜在泄漏。常用命令是：

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose ./myapp

其中：

立即学习“C++免费学习笔记（深入）”；

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• --leak-check=full：展开每块泄漏内存的完整调用栈（不是只报 summary）
• --show-leak-kinds=all：包括 definitely lost、indirectly lost、possibly lost、still reachable 四类（注意：still reachable 多数是全局指针持有，不一定是 bug）
• --track-origins=yes：对未初始化值问题，反向追踪来源（如某次 malloc 返回未初始化内存）
• 如果程序依赖 LD_PRELOAD 或有 fork 行为，加上 --trace-children=yes

怎么看懂泄漏报告里的关键字段

Valgrind 输出里最易混淆的是 definitely lost 和 still reachable。例如：

==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 2
==12345==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x4005AB: foo() (main.cpp:12)
==12345==    by 0x4005E0: main (main.cpp:20)

这说明 main.cpp 第 12 行调用 malloc 分配的内存，在程序退出时既没被 free，也没有任何指针指向它——基本就是泄漏。而：

==12345== 8 bytes in 1 blocks are still reachable in loss record 2 of 2
==12345==    at 0x4C2DB8F: malloc (vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x400605: bar() (main.cpp:33)
==12345==    by 0x4005E0: main (main.cpp:20)

表示第 33 行分配的内存，到程序结束仍有变量（比如全局 static char* g_buf）持有其地址。这类需人工判断是否合理——C++ 中单例对象内部缓存、日志缓冲区常属此类。

真正难处理的是 indirectly lost：它本身没被直接泄露，但所指对象的成员指针指向了 definitely lost 内存，导致整块对象不可达。这时要先解决根因的 definitely lost，再看它是否消失。