[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。

你可能感兴趣的:(C/C++)