转自：http://blog.csdn.net/zhangbinjn/archive/2009/08/13/4444641.aspx
今天写点工作相关的，同时给大家介绍工具（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内存分配的异常，导致内存大量的泄漏。
好了，就写这么多了，问题解决了，可以回家睡个好觉了。