vs2010内存断点_VS2010断点进不去解决方法 - CSDN博客

总结：删掉所有临时文件和输出文件，重编工程；不行再用UltraEdit打开出问题的文件，另存为ANSI编码、换行回车选择Unix 0x0A方式后，检查是否有乱码或者换行不对，应该都能解决。

问题如下:

1.错误代码报错行数错位? 2.debug动态跟踪错位? 3.Release跟踪错位? 4.断点设置自动被跳转

可能的原因有三种：

第一：

代码和dll或者exe不一致；

第二：

数组等越界导致内存乱了；

?

第三：

0D0A 改为了0D少了0A或者中文注释打乱了VS对0D0A的定位

?

方法一：

最方便的方法是静态编译看看是不是第三个原因，

首先VS的option里面把line number勾选出来，这样可以看到每行代码的行数，在断点错位的那行代码里面人为的添加几个语法错误，

然后编译，看看报错的代码行数是不是已经错位了，如果已经错位了，就是第三种情况，可以拿UE或者直接把中文注释全部删掉，

慢慢排查看看哪行换行符出了问题，简便办法是在随机的代码行里面人为添加语法错误，来逐步定位哪里几行的问题。

?

方法二：

1.挨个设断点,终于找到了首错位地址,呵呵,进步.? 2.偶怀疑是注释造成的问题,去掉全部的注释,再DEBUG,靠,还错位...? 3.把开始出问题的代码全部都注释吧...靠,还错位...? 4.这是什么问题,快疯掉了...? 5.把出问题的代码全部删除,咦,正常了..? 6.看来问题就出在被删除的代码上,不过看起来,代码一切正常啊,怎么会出问题呢?? 7.拿出UE来,看看代码中是否有非法字符(用十六进制的方式看)? 8.问题被看出来了,一般的代码与代码之间的换行是 0x0d 0x0a, 而这段代码中却有几行代码是 0x0d 没有0x0a...? ?? 到现在,我还没试出来怎样的情况下没有0x0a? 9.去掉0x0d,重新在IDE中"回车"? 10.再Debug,一切正常

折磨了我N多天的内存泄露bug终于解决了，当发现原因竟然是自己犯的那样弱智的一个错误时，真有种撞墙的冲动。现在就说说这次调试过程，血的教训！！以后写代码务必务必谨慎！！

程序写好了，拿两个数据文件做测试，调试通过，输出正常，OK~，然后就想测试一下所有的数据文件，看看结果是不是理想。写了一个批处理文件来遍历执行所有的文件，然后问题就出现了，大部分文件执行都是正常的，但执行到有些文件时，windows就会报错，只能跳过执行下一个文件。这就奇怪了，为什么会这样呢，这些文件都是符合ISO要求的模板，文件结构都一样，怎么有些就出错呢，难道是这些文件的数据量大，超出了变量的定义范围吗？

我记下那些出错的数据文件名称，单独用程序测试。编译过程没有问。。（也不应该有问题），在Debug下按F5执行的时候，就报错了，“Windows已在**.exe触发一个断点，其原因可能是堆被破坏，这也说明 **.exe 中或它所加载的任何 DLL 中有 bug。”但是每次执行错误位置指向不定，指向new.c 或者malloc.c或者free.c，虽然没看出这些文件能有什么问题，不过从名字上也大致知道这根内存操纵有关，在网上各种百度google 这个问题，大都说是因为操作了已经被释放内存空间的指针。我就从头至尾检查了几遍，确保不用的指针及时回收，每个new过的内存空间在适当的时候释放，不过几遍下来问题还是存在。

F10单步执行看看到底是哪句话出问题了，发现每次报错都是在一个类成员函数处，诡异的是这个成员函数在程序中被调用了两次，第一次是没有问题的，总是到第二次调用的时候报错。难道是这次调用的时候参数不同所致吗，按F11进去，一步一步的走，一直走到最后都没问题，在函数返回的时候又报错了，这会不会是参数返回时出问题了，检查了几遍之后发现参数返回，局部指针变量等都没问题。所以不管怎么加断点，单步跟程序，始终找不到问题出在哪。各种论坛上对这个问题的解释众说纷纭，反正归根结底一句话，这个跟自己具体的代码有关，没有统一的答案。当时就钻进死角了，就认为问题出在那个函数，但不管怎么折腾，错误依然存在。

这时在网上看到一种定位内存泄露的方法，这里推荐两篇文章http://www.gsm-guard.net/luckdst/item/137df9f16c3fbd11d6ff8c3f? ；http://www.gsm-guard.net/baobaodediaozhui/article/details/7466357；我就在程序的main函数所在的cpp文件中添加了这样一段代码

#define? _CRTDBG_MAP_ALLOC #include #include #ifdef? _DEBUG //#define new DEBUG_NEW #define new new(_CLIENT_BLOCK,__FILE__,__LINE__)????? ?//注意，这里是__? 不是_ #endif

inline void EnableMemLeakCheck() { ?_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)|_CRTDBG_LEAK_CHECK_DF); }

在main函数中添加：

EnableMemLeakCheck();

在其他的Cpp文件中添加代码：

#ifdef? _DEBUG //#define new DEBUG_NEW #define new new(_NORMAL_BLOCK,__FILE__,__LINE__) #endif

这样调试的时候就能看到内存泄露的new所在的位置，双击调试窗口的相应行，就定位到出错的位置，当我看到指向的位置时，又一次崩溃了，这个new在一个循环里，这个循环在一个类私有成员函数中，这个函数在程序中调用了N多次（N很大很大），我可判断不出来是那次调用出问题了。。。

心灰意冷地跟一个大牛聊这个问题，他说在内存泄露时，用断点跟踪这种方法确定的错误位置是不靠谱的，VS给出的错误位置也是不靠谱的。他说每次他遇到这种情况都是二分法注释掉一部分程序，然后一步步地缩小范围。我听了将信将疑，权且死马当活马医试试看吧。我先注释掉了出错的那个函数，结果让我大跌眼镜，错误果真还在，只是指向了后边另外一个函数，当时瞬间有种被欺骗的赶脚，敢情我花了那么长时间都是被VS玩了呀。然后我就依次注释掉了后边所有报错的函数，问题还是莫名其妙的存在，干脆我就注释掉了所有自己添加的代码，然后一步步的去掉注释调试，终于在添加一行代码时程序又报错了。。当时简直太兴奋了（第一次看到程序崩溃会这么开心）。然后就看那个函数能有什么问题。结果。。。问题还真找出来了，，我把一个数组的行和列弄反了。。竟然是这么个弱智的问题困扰了我这么多天。。。。还走了那么多弯路。。

现在想想除了写代码不仔细之外，还是自己调试程序的方法有问题，要是不钻死角，不自己死磕，多跳出来思考问题，多跟大牛请教，也许就不用浪费这么长时间了。。

?

Debug调试时进不去断点，提示：

The breakpoint will not currently be hit. The source code is different from original version.?

重新 rebuild 了，还是不行。后面关掉 vs ，重新打开，再次重新 rebuild 就可以了。