MFC编写完后程序内存泄漏，出不了界面

[xiaoYAN174]

环境是VS2013下的MFC，opencv3.0,添加的Apriltag程序。
MFC的程序是一点点累加出来的，基本上是加一点调试一点，都能运行出来。但是今天，也许是以往累积的内存泄漏量太多了，程序的界面都调不出来了，只是编译能成功。下载了VLD也只是显示泄漏，没显示具体泄漏位置。

[像我这么帅的只有一个]

Detected memory leaks! Dumping objects -> {52} normal block at 0x006D2498, 512 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {51} normal block at 0x006D2440, 24 bytes long. Data: < 4 > 10 34 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 Object dump complete. 这就是内存泄露。 具体是哪里发生了内存泄露呢，可以用_CrtSetBreakAlloc 来查找。 方法： 在程序中内存泄露开始之前，最好是程序启动的地方，加上下面的代码： _CrtSetBreakAlloc(52）； 调试启动Debug版程序，就会在这个地方触发断点， 这个时候我们利用 "调试" –> "退出" ,快捷键为:"Shift + F11" . 跳出当前函数..然后一直往"上"跳,边跳边查看调用栈.直到看到了自己写的代码，这就是内存泄露的地方啦。

[lx624909677]

_CrtSetBreakAlloc加在程序的入口函数处，还有vld最新版本的应该是能检测到具体的哪个函数的哪一行吧

[zgl7903]

#ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif

[worldy]

报泄漏一般都是虚报，在 属性--连接器---延时加载的dll 中，将opencv库的dll及其他外部的dll名称写入此处，一般就不会报泄漏 你的界面不显示一般不是泄漏的原因，还得仔细分析你的大妈的逻辑

[oyljerry]

在程序入口处就设置断点，然后单步跟踪一下，看看什么地方有问题

[zhujinqiang]

设断点，单步跟踪

[凌乱哥]

那个图片里不是有“对话框创建失败”吗 想想你今天加了什么代码，撤销回去试试

[我不是校长]

楼主的说法不对，VS内存泄漏的检测有就是有，不会说以前的少就不显示啊 你可以采用分离法，逐步排查 并且如果你加载的是OpenCV的dll本身就会有内存泄漏，你可以试试多处理几次看内存是否变化 内存泄漏本就是C++程序员的痛，所以建议使用Mat或者智能指针

[草履虫程序员]

单步跟踪调试,再用boundschecker

[l357630798]

用1楼 && 2楼 方法

[xiaoyilong19]

我的经验，就是大段大段地注释代码，或者是对比历史记录，查看和之前能行的时候区别，找到导致错误的代码，然后针对性地处理。比较实际，使用版本工具来对比的前提是你要及时签入自己的修改。

[走好每一步]

引用 11 楼 xiaoyilong19 的回复:

我的经验，就是大段大段地注释代码，或者是对比历史记录，查看和之前能行的时候区别，找到导致错误的代码，然后针对性地处理。比较实际，使用版本工具来对比的前提是你要及时签入自己的修改。

嗯，都是这么干的。 估计这不是内存泄漏的问题。

[xiaoYAN174]

后来我发现了，单纯创建一个MFC也会出现内存泄漏的情况。而上面之所以泄漏的这么厉害，是因为这个工程创建之初没有勾选ActiveX控件，而后来我往里添加某种ActiveX控件所致。如果这样，编译会没问题，但运行就会闪退，还出现大量内存泄漏。