一对MS内存泄漏查找工具（Leakdiag和LDGrapher）和STL类跨DLL调用引起内存泄漏

今天写点工作相关的，同时给大家介绍工具（Leakdiag和LDGrapher）。

这两个星期可以说是觉都没睡好，公司公测后运行的游戏，完成一个任务后内存飚到1G多，靠这游戏还能怎么玩，让玩家怎么玩啊，一个月几十万的充值势头，怕没两个星期就会掉下去。这几天一直和主程不停的查找原因。

当然，这么大的内存泄漏，最引起我们注意的当然就是图形引擎这一块了，只有地图、光效和图片资源才会占用如此大的内存。但因为引擎代码是另外项目组在维护，给我们的只是一些库文件，所以没有办法，我们只能对每一个通过底层接口频繁的调用来测试底层的问题（只有拿出证据，你才有说话的权力）。但是，最后的结果让我们失望，通过反复的测试，排除底层的问题。

当然，进一步，我们又从调用特别繁琐的寻路算法进行排除，发现也不是其中的原因。真的是山穷水尽了，大家整的都很疲惫。内存还是飚，问题还是要解决。

 

可能大家看到标题，我写了这么多的费话可能，你会问题，你们早一点没有想到找一个工具测一下啊。这个当然是首先想到的，不断的去找的，不然要不会介绍今天的Leakdiag和LDGrapher，开始找了很多的工具去试去配，但是都没有达到想要的结果。最后，微软的Leakdiag和LDGrapher凳场了，也给我们带来了光明。（得出一个结论：要用工具，要用好工具，要用对工具）。应该有很多人知道了其强大性，这里再强调一个，我相信，中国的程序员应该学会一点，那就是好工具大家用，好资料大家看，好代码大家学习的分享精神。

 

不说费话，网上有几篇介绍Leakdiag和LDGrapher的文章，说的也算详细：

http://www.cppblog.com/sandy/archive/2008/08/18/59260.html

 

还有几点要强调：

1、log下来的并不是内存泄漏的，而是你运行开始，分配了还没有释放的；

2、log的堆栈可以设置为1-32,所以足够你定位错误代码（Tools设置）；

3、在你认为的关键点打几个log，用LDGrapher线谱图可以很明显的看出内存分配的情况。

 

当然，最后写一下出问题的原因，也是大多数有一定项目经验的人都会遇到的STL类跨DLL调用的问题。这个问题的讨论也很多，google一下你会有很大的收获。

http://www.cppblog.com/fwxjj/archive/2009/06/16/87810.html

http://www.cppblog.com/xingmuxixi/archive/2009/05/18/83281.html

我们这次遇到的主要问题是在一个Dll中的接口中返回了一个std::vector的值对象，在.exe文件中用了这接口，对返回的vector做了操作，也就是说，一个在Dll中创建的STL对象，在.exe中释放的时候，会造成STL内存分配的异常，导致内存大量的泄漏。

 

好了，就写这么多了，问题解决了，可以回家睡个好觉了。