valgrind测试内存泄露

valgrind内存检测中五种内存丢失的解释

结果示例：
LEAK SUMMARY:
definitely lost: 140 bytes in 5 blocks.
indirectly lost: 1,252 bytes in 41 blocks.
possibly lost: 0 bytes in 0 blocks.
still reachable: 36 bytes in 1 blocks.
suppressed: 0 bytes in 0 blocks.

1) still reachable: 表示泄漏的内存在程序运行完的时候，仍旧有指针指向它，因而，这种内存在程序运行结束之前可以释放。一般情况下valgrind不会报这种泄漏，除非使用了参数 --show-reachable=yes。

2) definitely losg: 明确地已经泄漏了，因为在程序运行完的时候，没有指针指向它, 指向它的指针在程序中丢失了。一般这种泄漏常见，而且比较难发现问题所在。

3) indirectly lost: 间接地 ????????????????

4) possibly lost: 发现了一个指向某块内存中部的指针，而不是指向内存块头部。这种指针一般是原先指向内存块头部，后来移动到了内存块的中部，还有可能该指针和该内存根本就没有关系，检测工具只是怀疑有内存泄漏。

5) suppressed:

 

http://hi.baidu.com/andrewnwpu/blog/item/006a770e577785c17bcbe1bc.html

内存泄露

问题描述：

内存泄露（Memory leak）指的是，在程序中动态申请的内存，在使用完后既没有释放，又无法被程序的其他部分访问。内存泄露是在开发大型程序中最令人头疼的问题，以至于有人说，内存泄露是无法避免的。其实不然，防止内存泄露要从良好的编程习惯做起，另外重要的一点就是要加强单元测试（Unit Test），而memcheck就是这样一款优秀的工具。

下面是一个比较典型的内存泄露案例。main函数调用了mk函数生成树结点，可是在调用完成之后，却没有相应的函数：nodefr释放内存，这样内存中的这个树结构就无法被其他部分访问，造成了内存泄露。

在一个单独的函数中，每个人的内存泄露意识都是比较强的。但很多情况下，我们都会对malloc/free 或new/delete做一些包装，以符合我们特定的需要，无法做到在一个函数中既使用又释放。这个例子也说明了内存泄露最容易发生的地方：即两个部分的接口部分，一个函数申请内存，一个函数释放内存。并且这些函数由不同的人开发、使用，这样造成内存泄露的可能性就比较大了。这需要养成良好的单元测试习惯，将内存泄露消灭在初始阶段。

清单 11
 

清单 11.2
 

清单 11.3
 

结果分析：

假设上述文件名位tree.h, tree.cpp, badleak.cpp，生成的可执行程序为badleak，用memcheck对其进行测试，输出如下。

清单 12
 

该示例程序是生成一棵树的过程，每个树节点的大小为12（考虑内存对齐），共8个节点。从上述输出可以看出，所有的内存泄露都被发现。Memcheck将内存泄露分为两种，一种是可能的内存泄露（Possibly lost），另外一种是确定的内存泄露（Definitely lost）。Possibly lost 是指仍然存在某个指针能够访问某块内存，但该指针指向的已经不是该内存首地址。Definitely lost 是指已经不能够访问这块内存。而Definitely lost又分为两种：直接的（direct）和间接的（indirect）。直接和间接的区别就是，直接是没有任何指针指向该内存，间接是指指向该内存的指针都位于内存泄露处。在上述的例子中，根节点是directly lost，而其他节点是indirectly lost。

回页首

总结

本文介绍了valgrind的体系结构，并重点介绍了其应用最广泛的工具：memcheck。阐述了memcheck发现内存问题的基本原理，基本使用方法，以及利用memcheck如何发现目前开发中最广泛的五大类内存问题。在项目中尽早的发现内存问题，能够极大地提高开发效率，valgrind就是能够帮助你实现这一目标的出色工具。