调试MFC内存泄露——实战分析
2009-11-13 10:13
232 查看
首先,应该是MFC报告我们发现内存泄漏。注意:要多运行几次,以确定输出的内容不变,特别是{}之间的数值,不能变,否则下面的方法就不好用了:
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/LeakOut.JPG)
我们来看看:
F: CodeSample Test TestPipe LeakTest MainFrm.cpp(54) : {86} normal block at 0x00422E80, 10 bytes long.
Data: < > 1F 1F 1F 1F 1F CD CD CD CD CD
F: CodeSample Test TestPipe LeakTest MainFrm.cpp(54) 告诉我们MFC认为是在该文件的54行,发生了内存泄漏。你双击改行就可以转到该文件的54行了。但是有时候这一信息并不能用来准确判断,比如:MFC可能报告Strcore.cpp文件的某行,实际上这是CString的实现函数,此时并不知道什么时候发生了内存泄漏。
此时我们需要更多的信息。那么我们看看紧接其后的:
{86} normal block at 0x00422E80, 10 bytes long.
Data: < > 1F 1F 1F 1F 1F CD CD CD CD CD
它告诉我们:在第86次分配的内存没有释放,一共有10字节,内容移16进制方式打印给我们看。
有了这些信息,我们可以开始调试内存泄漏了。
按下F10在程序的刚开始处,停下来,打开Watch窗口:
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/LeakWatchMenu.JPG)
在Watch窗口中输入:
{,,msvcrtd.dll}_crtBreakAlloc
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/watch1.JPG)
然后更改值为上文提到的分配次数:86
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/watch2.JPG)
接着按下F5继续,然后在第86次分配的时候会发生中断:
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/MessageBox.JPG)
然后我们打开堆栈窗口:
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/LeakStackMenu.JPG)
可以看到如下信息:
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/ClickStack.JPG)
往回查看最近我们自己的代码,双击堆栈我们自己的函数那一层,上图有绿色三角的那一层。就定位到泄漏时分配的内存了。
![](http://www.cnitblog.com/images/cnitblog_com/wangk/MFCLeak/FoundLeak.JPG)
之后,就是看你的编码功底了......
本文转自:http://white313.blog.163.com/blog/static/21026200611903653959/
相关文章:免费的内存泄漏检测工具Visual Leak Detector
我们来看看:
F: CodeSample Test TestPipe LeakTest MainFrm.cpp(54) : {86} normal block at 0x00422E80, 10 bytes long.
Data: < > 1F 1F 1F 1F 1F CD CD CD CD CD
F: CodeSample Test TestPipe LeakTest MainFrm.cpp(54) 告诉我们MFC认为是在该文件的54行,发生了内存泄漏。你双击改行就可以转到该文件的54行了。但是有时候这一信息并不能用来准确判断,比如:MFC可能报告Strcore.cpp文件的某行,实际上这是CString的实现函数,此时并不知道什么时候发生了内存泄漏。
此时我们需要更多的信息。那么我们看看紧接其后的:
{86} normal block at 0x00422E80, 10 bytes long.
Data: < > 1F 1F 1F 1F 1F CD CD CD CD CD
它告诉我们:在第86次分配的内存没有释放,一共有10字节,内容移16进制方式打印给我们看。
有了这些信息,我们可以开始调试内存泄漏了。
按下F10在程序的刚开始处,停下来,打开Watch窗口:
在Watch窗口中输入:
{,,msvcrtd.dll}_crtBreakAlloc
然后更改值为上文提到的分配次数:86
接着按下F5继续,然后在第86次分配的时候会发生中断:
然后我们打开堆栈窗口:
可以看到如下信息:
往回查看最近我们自己的代码,双击堆栈我们自己的函数那一层,上图有绿色三角的那一层。就定位到泄漏时分配的内存了。
之后,就是看你的编码功底了......
本文转自:http://white313.blog.163.com/blog/static/21026200611903653959/
相关文章:免费的内存泄漏检测工具Visual Leak Detector
相关文章推荐
- 如何调试MFC中的内存泄露
- 关于DLL工程中存在全局变量可能导致MFC内存泄露误报的原因分析及解决办法
- 非MFC的C++内存泄露跟踪与调试
- 关于DLL工程中存在全局变量可能导致MFC内存泄露误报的原因分析及解决办法
- 【Android程序优化,避免内存泄露】- [实战一]:避免内存泄露的最后一道墙,使用leakcanary分析程序中的内存泄露。
- 关于DLL工程中存在全局变量可能导致MFC内存泄露误报的原因分析及解决办法
- Android 内存分析及管理、泄露和调试
- 分析和解决JAVA 内存泄露的实战例子
- 内存泄露调试技巧(转)-关于MFC下检查和消除内存泄露的技巧
- 非MFC的C++内存泄露跟踪与调试
- android 内存泄露分析及调试(LeakCanary使用)
- 【Android程序优化,避免内存泄露】- [实战一]:避免内存泄露的最后一道墙,使用leakcanary分析程序中的内存泄露。
- Android学习系列(32)--App调试内存泄露之Cursor篇
- 挖掘内存最大潜力 实战分析2G内存同4G内存之差别
- Android内存泄露分析之StrictMode
- 内存不足(OutOfMemory)的调试分析
- 使用Handler造成内存泄露的分析和解决办法
- 能调试---(四)内存性能分析
- Android 性能优化之使用MAT分析内存泄露问题
- 利用MemoryAnalyzer分析内存泄露