[DEBUG]内存泄露调试

呼。。又是一次痛苦的调试经历，赶紧记点心得吧。虽然是一个很傻X的失误，但是经历的过程还是收获蛮多的。开始之前，顺便透露一下，关于shero，我已经决定做一个单机开源RPG了，最迟在5月发布吧，最终效果相信不会令大家失望。。:)

好了，起因是这样的，因为集成了CEGUI，界面基本搭好时，却发现有严重的内存泄露，至少当时我是这样认为的，然后便开始尝试各种办法，没有结果。其实最后才发现，原因很简单，我自己的项目里加入了这个设置：

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_DELAY_FREE_MEM_DF | _CRTDBG_CHECK_EVERY_1024_DF | _CRTDBG_CHECK_CRT_DF);

_CRTDBG_DELAY_FREE_MEM_DF，我傻B了，英语白学了。在加入CEGUI以前，项目的每轮循环里不会都有new 与 delete的操作，自然看不出啥问题，但是有了CEGUI后就不一样了，new分配的空间是延迟释放的，不断堆积后看上去肯定就是严重的内存泄露了！

上面的不是重点，重点是过程中的一点调试心得，简单记录下吧：

1，关于内存泄露检测，VC环境下可以检测的，http://shallway.net/blog/?p=337这里的DEBUG_NEW有提到。

但是，这种方法不能解决2个问题：

1. 如果内存泄露是在附加库或者Dll中，调试输出窗口显示的信息不包括源文件地址
2. 通常更诡异的内存泄露是这样的：程序运行中不断积累，程序退出时却会一起释放的，这种情况是检测不出的。

对于1，一个很有用的技巧是，调试输出窗口不会显示源文件地址，但是会显示这个未分配Block的ID，知道这个ID后，在程序中加入_CrtSetBreakAlloc(ID)，再运行程序，就会在分配这个BLock时中断，这样调试就有堆栈输出窗口了，这样就可以知道是附加模块哪里的问题了。

对于2，除开其他调试技巧，其实用1的办法也会有帮助，那就是在_CrtSetBreakAlloc(ID)里，不断更改ID值，视具体情况，达到对问题根源的准确定位。

 

2，关于Release下运行出现指针访问错误，Debug下却没问题的可能原因：

1. 检查DEBUG下所有warning
2. 某些函数不是每个路径都有返回值
3. 对象构造函数里不是对每个成员变量都做了初始化（这个最有可能）

也可能有其他原因，以后再整理。OVER。