浅谈MFC内存泄露检测及内存越界访问保护机制
本文所有代码均在VC2008下编译、调试。如果您使用的编译器不同，结果可能会有差别，但本文讲述的原理对于大部分编译器应该是相似的。对于本文的标题，实在不知道用什么表示更恰当，因为本文不仅淡了内存泄露检测机制，也谈到了指针越界的检测机制。到底应该说是MFC的机制，还是C++的机制？Anyway，相信你看了一定会有所收获。并欢迎常来本博客http://lionel.bokee.com留言讨论。 在我们开发MFC应用程序的时候，不知大家是否注意到Debug版本输出窗口经常会有下面这样的信息：
Detected memory leaks!
Dumping objects ->
c:\my.data\my.codes\memleak\memleak\memleak.cpp(34) : {126} normal block at 0x00A321A0, 4 bytes long.
Data: < > 01 00 00 00
Object dump complete. 编译器是怎么知道我们写的代码有内存泄露并能精确到文件、行号的呢？事实上也并不是所有情况都能精确到文件、行号，看看下面这种情况：
Detected memory leaks!
Dumping objects ->
First-chance exception at 0x75c739e5 (kernel32.dll) in MemLeak.exe:
0xC0000005: Access violation reading location 0x711af9f4.
#File Error#(62) : {137} normal block at 0x00A721A0, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete. 虽然检测出了内存泄露，但我们只能知道内存地址、行号，文件名是#File Error#，而且还伴随着内存非法访问的异常。这个异常看似是MFC在检测内存泄露的时候产生的。 下面我们从C++内存分配与回收的两个操作符new, delete一步步分析C++内存管理以及MFC内存泄露检测机制。所有这些都是针对Debug版本的，最后我们再看看Release版本的情况。
一、内存分配操作符new 新建一个MFC应用程序，无论是Win32 Console Application + MFC Support，还是MFC Application或者是MFC DLL。编译器为我们生成的代码最前面，在#include下面都会有下面这三行代码：
#ifdef _DEBUG
#define new DEBUG_NEW
#endif 这三句话的意思是，如果是Debug版本，那么将new操作符定义为DEBUG_NEW。在afx.h中有对DEBUG_NEW的定义：
// Memory tracking allocation
void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine);
#define DEBUG_NEW new(THIS_FILE, __LINE__) 看来MFC是重新定义了一个new操作符，并把文件名、行号调试信息传给了new。下面是这个new操作符调用的其它函数。可见是按照MFC -> C++ -> C -> Win32 API的流程分配的内存：
DEBUG_NEW
-> void* __cdecl operator new(size_t nSize, LPCSTR lpszFileName, int nLine) afxmem.cpp
-> void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine) afxmem.cpp
-> extern "C" _CRTIMP void* __cdecl _malloc_dbg(…) dbgheap.c
-> extern "C" void* __cdecl _nh_malloc_dbg(…) dbgheap.c
-> extern "C" static void * __cdecl _nh_malloc_dbg_impl(…) dbgheap.c
-> extern "C" static void * __cdecl _heap_alloc_dbg_impl(…) dbgheap.c
-> __forceinline void * __cdecl _heap_alloc (size_t size) malloc.c
-> LPVOID WINAPI HeapAlloc(…); winbase.h二、内存回收操作符delete MFC并没有重新定义delete操作符，因为所有调试信息已经传给了new操作符。delete操作符只要依然按照MFC -> C++ -> C -> Win32 API的流程将之前分配的内存释放掉就可以了：
operator delete
-> class CCRTAllocator::static void Free(void* p) throw() atlalloc.h
-> extern "C" _CRTIMP void __cdecl _free_dbg(void * pUserData, int nBlockUse) dbgheap.c
-> extern "C" void __cdecl _free_dbg_nolock(void * pUserData, int nBlockUse) dbgheap.c
-> void __cdecl _free_base (void * pBlock) free.c
-> BOOL WINAPI HeapFree(…); winbase.h三、C++内存链 内存链是MFC检测内存泄露的基础，当我们每new一块内存，_heap_alloc_dbg_impl就会把这块内存加入内存链，当我们delete一块内存，_free_dbg_nolock就会把这块内存从内存链中删除。VC的实现是使用了一个双向链表。每一个节点的结构定义如下：
typedef struct _CrtMemBlockHeader
{
struct _CrtMemBlockHeader * pBlockHeaderNext; // 下一个节点指针
struct _CrtMemBlockHeader * pBlockHeaderPrev; // 前一个节点指针
char * szFileName; // 调用new的文件名
int nLine; // 调用new的行号
size_t nDataSize; // 调用new分配内存大小
int nBlockUse; // 本块内存使用目的
long lRequest; // 请求编号
unsigned char gap[nNoMansLandSize]; // 内存前面的空白
/* followed by:
* unsigned char data[nDataSize]; // 真正的内存
* unsigned char anotherGap[nNoMansLandSize]; // 内存后面的空白
*/
} _CrtMemBlockHeader; 结构体中有几个成员可能需要解释一下。nBlockUse表示本块内存的用途，一般取值为_NORMAL_BLOCK。lRequest表示请求内存的编号，初始值为1，每请求一次，该值加1。我们在输出窗口看到的normal block就表示nBlockUse=_NORMAL_BLOCK， {137} 就是lRequest的值。data是真正返回给我们的指针，编译器在data前后用gap, anotherGap将数据保护起来并赋予特殊的值，以检测我们对指针操作是否越界。这些空白区域内存大小为#define nNoMansLandSize 4。data同样被赋予特殊的值，特殊值总共有四种：
static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */
static unsigned char _bAlignLandFill = 0xED; /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill = 0xDD; /* fill free objects with this */
static unsigned char _bCleanLandFill = 0xCD; /* fill new objects with this */比如说我们new了一个int对象，int* p = new int；那么上面这个结构体内容如下：
+------------------------------------------------------------------------------+
| pBlockHeaderNext | …… | gap: FDFDFDFD | p: CDCDCDCD | anotherGap: FDFDFDFD |
+------------------------------------------------------------------------------+ 比如说我们内存访问越界了：*(p+1) = 0，那么在delete这个指针的时候，_free_dbg_nolock会对gap, anotherGap的值进行检查，发现不等于_bNoMansLandFill，就报错。如果我们写*(p+1) = 0xFDFDFDFD，那么就把编译器骗了，编译器认为内存访问并没有越界。当我们delete一块内存的时候，这块内存会被用_bDeadLandFill填充。如果我们new了多个对象，那么这些对象就链接再了一起，例如：
int* pB = new int;
int* pA = new int;内存布局如下：
+--------------------------------------------------------------------------+
| +--------------------------+ +--------------------------+ |
+-> | pHead = pBlockHeaderNext | -----------> | pBlockHeaderNext = NULL | |
|--------------------------| |--------------------------| |
| pBlockHeaderPrev = NULL | | pBlockHeaderPrev ->-|-+
|--------------------------| |--------------------------|
| ...... | | ...... |
|--------------------------| |--------------------------|
|gap: FDFDFDFD | |gap: FDFDFDFD |
|--------------------------| |--------------------------|
|pA: CDCDCDCD | |pB: CDCDCDCD |
|--------------------------| |--------------------------|
|anotherGap: FDFDFDFD | |anotherGap: FDFDFDFD |
+--------------------------+ +--------------------------+ 知道了内存块的布局，我们甚至可以通过一个指针，打印出当前new过的所有对象内存地址及大小。为了验证上述内容的正确性，我们不妨写一个简单的验证程序：
int* pB = new int(2);
int* pA = new int(1);cout << "*pA = " << *pA << ", *pB = " << *pB << endl; // *pA = 1, *pB = 2*((int*)(*(pA - 8)) + 8) = 1;
*((int*)(*(pB - 7)) + 8) = 2;cout << "*pA = " << *pA << ", *pB = " << *pB << endl; // *pA = 2, *pB = 1delete pA;
delete pB;四、内存泄露检测机制 MFC正是因为有了内存链，才可以检测出哪些内存还没有被释放。在程序退出的时候，dbgheap.c中的extern "C" _CRTIMP int __cdecl _CrtDumpMemoryLeaks(void)函数会被调用，然后遍历当前的内存链，看看还有哪些内存没有被释放，然后打印出内存泄露的信息。原理很简单，这里不再赘述。那么为什么有的情况下我们无法通过输出的信息定位到具体泄露的文件呢？为什么有的时候会显示#File Error#？看看上面提到的结构体中文件名的保存char * szFileName，仅仅保存了一个指向文件名的指针而已。这个文件名是作为一个字符串，保存在.exe或.dll的.rdata中的。如果在.exe文件退出的时候，我们显式加载的.dll文件已经被我们卸载了，并且在该.dll文件内存存在内存泄露的话，虽然_CrtDumpMemoryLeaks会尝试读取并显示文件名，但szFileName指针指向的内存空间已经是无效的了。_CrtDumpMemoryLeaks在读取文件名之前会先调用API函数IsBadReadPtr判断该指针是否有效。如果已经无效则显示#File Error#。本文最开始所提到的异常，正是由IsBadReadPtr导致的。
五、Release版本 对于Release版本，就没有上面提到的内存链了。对于new和delete的调用将会被直接转到malloc.c和free.c。因为没有内存链，没有多余的保护数据填充，没有内存越界检测机制，所以有些时候Debug版本会崩溃，但是Release版本却没有。这并不代表代码没有问题，而是内存非法访问更难发现了，当Release版本崩溃的时候，问题也更难定位了。
上述内存泄露检测、内存越界访问检测的原理很简单，但并不能查出所有内存非法访问。所以永远不要乱用指针，然后把所有对指针的判断都用try{}catch{}规避。因为并不是所有指针非法访问都能catch到，即使catch到了，内存也可能已经被写坏了。
关于MFC下检查和消除内存泄露的技巧
作者：freepublic
摘要
本文分析了Windows环境使用MFC调试内存泄露的技术，介绍了在Windows环境下用VC++查找，定位和消除内存泄露的方法技巧。
关键词：VC++；CRT 调试堆函数；试探法。
编译环境
VC++6.0
技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include
#include
注意 #include 语句必须采用上文所示顺序。如果更改了顺序，所使用的函数可能无法正确工作。
通过包括 crtdbg.h，将 malloc 和 free 函数映射到其“Debug”版本_malloc_dbg 和_free_dbg，这些函数将跟踪内存分配和释放。此映射只在调试版本（在其中定义了 _DEBUG）中发生。发布版本使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。并非绝对需要该语句，但如果没有该语句，内存泄漏转储包含的有用信息将较少。
在添加了上面所示语句之后，可以通过在程序中包括以下语句来转储内存泄漏信息：
_CrtDumpMemoryLeaks();
当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。内存泄漏信息如下所示：
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：
Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是：
内存分配编号（在大括号内）。
块类型（普通、客户端或 CRT）。
十六进制形式的内存位置。
以字节为单位的块大小。
前 16 字节的内容（亦为十六进制）。
定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。文件名后括号中的数字（本示例中为 20）是该文件内的行号。
转到源文件中分配内存的行
在"输出"窗口中双击包含文件名和行号的行。
-或-
在"输出"窗口中选择包含文件名和行号的行，然后按 F4 键。
_CrtSetDbgFlag
如果程序总在同一位置退出，则调用 _CrtDumpMemoryLeaks 足够方便，但如果程序可以从多个位置退出该怎么办呢？不要在每个可能的出口放置一个对 _CrtDumpMemoryLeaks 的调用，可以在程序开始包括以下调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如上所示。
说明
在VC++6.0的环境下，不再需要额外的添加
#define CRTDBG_MAP_ALLOC
#include
#include
只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现
Detected memory leaks!
Dumping objects ->
就有内存泄露。
确定内存泄露的地方
根据内存泄露的报告，有两种消除的方法：
第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20)
就是源文件名称和行号。
第二种比较麻烦，就是不能映射到源文件的，只有内存分配块号。
Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
这种情况我采用一种"试探法"。由于内存分配的块号不是固定不变的，而是每次运行都是变化的，所以跟踪起来很麻烦。但是我发现虽然内存分配的块号是变化的，但是变化的块号却总是那几个，也就是说多运行几次，内存分配的块号很可能会重复。因此这就是"试探法"的基础。
1. 先在调试状态下运行几次程序，观察内存分配的块号是哪几个值；
2. 选择出现次数最多的块号来设断点，在代码中设置内存分配断点： 添加如下一行（对于第 18 个内存分配）：
_crtBreakAlloc = 18;
或者，可以使用具有同样效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(18);
3. 在调试状态下运行序，在断点停下时，打开"调用堆栈"窗口，找到对应的源代码处；
4. 退出程序，观察"输出窗口"的内存泄露报告，看实际内存分配的块号是不是和预设值相同，如果相同，就找到了；如果不同，就重复步骤3，直到相同。
5. 最后就是根据具体情况，在适当的位置释放所分配的内存。
(全文完)
（转完整）VC内存泄露检测
2009-10-28 21:15
最近看了周星星 Blog 中的一篇文章：“VC++6.0中内存泄漏检测”，受益匪浅，便运行其例子代码想看看 Output 窗口中的输出结果，可惜怎么弄其输出都不是预期的东西，郁闷了半天，便到水坛里找到周星星，请求他指点一、二，然而未果。没有办法，最后我一头栽进 MSDN 库狂搜了一把，功夫不负有心人，我搜出很多有关这方面的资料，没过多久我便基本上就找到了答案......
首先，检测内存泄漏的基本工具是调试器和 CRT 调试堆函数。为了使用调试堆函数，必须在要检测内存泄漏和调试的程序中添加下面的语句：
#define _CRTDBG_MAP_ALLOC #include #include #include "debug_new.h"
MSDN 如是说：“必须保证上面声明的顺序，如果改变了顺序，可能不能正常工作。”至于这是为什么，我们不得而知。MS 的老大们经常这样故弄玄虚。
针对非 MFC 程序，再加上周星星的头文件：（1）debug_new.h，当然如果不加这一句，也能检测出内存泄漏，但是你无法确定在哪个源程序文件中发生泄漏；（2）我们来模拟下MFC做的事情。看下例：
inline void EnableMemLeakCheck()
{
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}
#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif
void main()
{
EnableMemLeakCheck();
int* leak = new int[10];
}
。Output 输出只告诉你在 crtsdb.h 中的某个地方有内存泄漏。我测试时 REG_DEBUG_NEW 没有起作用。加不加这个宏都可以检测出发生内存分配泄漏的文件。
其次，一旦添加了上面的声明，你就可以通过在程序中加入下面的代码来报告内存泄漏信息了：
_CrtDumpMemoryLeaks(); 这就这么简单。我在周星星的例子代码中加入这些机关后，在 VC++ 调试会话（按 F5 调试运行） Output 窗口的 Debug 页便看到了预期的内存泄漏 dump。该 dump 形式如下：
Detected memory leaks! Dumping objects -> c:\Program Files\...\include\crtdbg.h(552) : {45} normal block at 0x00441BA0, 2 bytes long. Data: 41 42 c:\Program Files\...\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long. Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD c:\Program Files\...\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long. Data: < C > E8 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00 Object dump complete.
更具体的细节请参考本文附带的源代码文件。
下面是我看过 MSDN 资料后，针对“如何使用 CRT 调试功能来检测内存泄漏？”的问题进行了一番编译和整理，希望对大家有用。如果你的英文很棒，那就不用往下看了，建议直接去读 MSDN 库中的技术原文。
C/C++ 编程语言的最强大功能之一便是其动态分配和释放内存，但是中国有句古话：“最大的长处也可能成为最大的弱点”，那么 C/C++ 应用程序正好印证了这句话。在 C/C++ 应用程序开发过程中，动态分配的内存处理不当是最常见的问题。其中，最难捉摸也最难检测的错误之一就是内存泄漏，即未能正确释放以前分配的内存的错误。偶尔发生的少量内存泄漏可能不会引起我们的注意，但泄漏大量内存的程序或泄漏日益增多的程序可能会表现出各种 各样的征兆：从性能不良（并且逐渐降低）到内存完全耗尽。更糟的是，泄漏的程序可能会用掉太多内存，导致另外一个程序垮掉，而使用户无从查找问题的真正根源。此外，即使无害的内存泄漏也可能殃及池鱼。
幸运的是，Visual Studio 调试器和 C 运行时 (CRT) 库为我们提供了检测和识别内存泄漏的有效方法。下面请和我一起分享收获——如何使用 CRT 调试功能来检测内存泄漏？
如何启用内存泄漏检测机制？
使用 _CrtSetDbgFlag
设置 CRT 报告模式
解释内存块类型
如何在内存分配序号处设置断点？
如何比较内存状态？
结论
如何启用内存泄漏检测机制？
VC++ IDE 的默认状态是没有启用内存泄漏检测机制的，也就是说即使某段代码有内存泄漏，调试会话的 Output 窗口的 Debug 页不会输出有关内存泄漏信息。你必须设定两个最基本的机关来启用内存泄漏检测机制。
一是使用调试堆函数：
#define _CRTDBG_MAP_ALLOC #include #include
注意：#include 语句的顺序。如果更改此顺序，所使用的函数可能无法正确工作。
通过包含 crtdbg.h 头文件，可以将 malloc 和 free 函数映射到其“调试”版本 _malloc_dbg 和 _free_dbg，这些函数会跟踪内存分配和释放。此映射只在调试（Debug）版本（也就是要定义 _DEBUG）中有效。发行版本（Release）使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基础版本映射到对应的“调试”版本。该语句不是必须的，但如果没有该语句，那么有关内存泄漏的信息会不全。
二是在需要检测内存泄漏的地方添加下面这条语句来输出内存泄漏信息：
_CrtDumpMemoryLeaks(); 当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在 Output 窗口的 Debug 页中显示内存泄漏信息。比如：
Detected memory leaks!Dumping objects ->C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long.Data: 41 42 c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long.Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long.Data: < C > 08 02 43 00 16 00 00 00 00 00 00 00 00 00 00 00 Object dump complete.
如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏的输出是这样的：
Detected memory leaks!Dumping objects ->{45} normal block at 0x00441BA0, 2 bytes long.Data: 41 42 {44} normal block at 0x00441BD0, 33 bytes long.Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD {43} normal block at 0x00441C20, 40 bytes long.Data: < C > C0 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00 Object dump complete. 根据这段输出信息，你无法知道在哪个源程序文件里发生了内存泄漏。下面我们来研究一下输出信息的格式。第一行和第二行没有什么可说的，从第三行开始：
xx}：花括弧内的数字是内存分配序号，本文例子中是 {45}，{44}，{43}；block：内存块的类型，常用的有三种：normal（普通）、client（客户端）或 CRT（运行时）；本文例子中是：normal block； 用十六进制格式表示的内存位置，如：at 0x00441BA0 等；以字节为单位表示的内存块的大小，如：32 bytes long； 前 16 字节的内容（也是用十六进制格式表示），如：Data: 41 42 等；
仔细观察不难发现，如果定义了 _CRTDBG_MAP_ALLOC ，那么在内存分配序号前面还会显示在其中分配泄漏内存的文件名，以及文件名后括号中的数字表示发生泄漏的代码行号，比如：
C:\Temp\memleak\memleak.cpp(15) 双击 Output 窗口中此文件名所在的输出行，便可跳到源程序文件分配该内存的代码行（也可以选中该行，然后按 F4，效果一样） ，这样一来我们就很容易定位内存泄漏是在哪里发生的了，因此，_CRTDBG_MAP_ALLOC 的作用显而易见。
使用 _CrtSetDbgFlag
如果程序只有一个出口，那么调用 _CrtDumpMemoryLeaks 的位置是很容易选择的。但是，如果程序可能会在多个地方退出该怎么办呢？在每一个可能的出口处调用 _CrtDumpMemoryLeaks 肯定是不可取的，那么这时可以在程序开始处包含下面的调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
这条语句无论程序在什么地方退出都会自动调用 _CrtDumpMemoryLeaks。注意：这里必须同时设置两个位域标志：_CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF。
设置 CRT 报告模式
默认情况下，_CrtDumpMemoryLeaks 将内存泄漏信息 dump 到 Output 窗口的 Debug 页， 如果你想将这个输出定向到别的地方，可以使用 _CrtSetReportMode 进行重置。如果你使用某个库，它可能将输出定向到另一位置。此时，只要使用以下语句将输出位置设回 Output 窗口即可：
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );
有关使用 _CrtSetReportMode 的详细信息，请参考 MSDN 库关于 _CrtSetReportMode 的描述。
解释内存块类型
前面已经说过，内存泄漏报告中把每一块泄漏的内存分为 normal（普通块）、client（客户端块）和 CRT 块。事实上，需要留心和注意的也就是 normal 和 client，即普通块和客户端块。
normal block（普通块）：这是由你的程序分配的内存。
client block（客户块）：这是一种特殊类型的内存块，专门用于 MFC 程序中需要析构函数的对象。MFC new 操作符视具体情况既可以为所创建的对象建立普通块，也可以为之建立客户块。
CRT block（CRT 块）：是由 C RunTime Library 供自己使用而分配的内存块。由 CRT 库自己来管理这些内存的分配与释放，我们一般不会在内存泄漏报告中发现 CRT 内存泄漏，除非程序发生了严重的错误（例如 CRT 库崩溃）。
除了上述的类型外，还有下面这两种类型的内存块，它们不会出现在内存泄漏报告中：
free block（空闲块）：已经被释放(free)的内存块。
Ignore block（忽略块）：这是程序员显式声明过不要在内存泄漏报告中出现的内存块。
如何在内存分配序号处设置断点？
在内存泄漏报告中，的文件名和行号可告诉分配泄漏的内存的代码位置，但仅仅依赖这些信息来了解完整的泄漏原因是不够的。因为一个程序在运行时，一段分配内存的代码可能会被调用很多次，只要有一次调用后没有释放内存就会导致内存泄漏。为了确定是哪些内存没有被释放，不仅要知道泄漏的内存是在哪里分配的，还要知道泄漏产生的条件。这时内存分配序号就显得特别有用——这个序号就是文件名和行号之后的花括弧里的那个数字。
例如，在本文例子代码的输出信息中，“45”是内存分配序号，意思是泄漏的内存是你程序中分配的第四十五个内存块：
Detected memory leaks!Dumping objects ->C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long.Data: 41 42 ......Object dump complete.
CRT 库对程序运行期间分配的所有内存块进行计数，包括由 CRT 库自己分配的内存和其它库（如 MFC）分配的内存。因此，分配序号为 N 的对象即为程序中分配的第 N 个对象，但不一定是代码分配的第 N 个对象。（大多数情况下并非如此。）
这样的话，你便可以利用分配序号在分配内存的位置设置一个断点。方法是在程序起始附近设置一个位置断点。当程序在该点中断时，可以从 QuickWatch（快速监视）对话框或 Watch（监视）窗口设置一个内存分配断点：
例如，在 Watch 窗口中，在 Name 栏键入下面的表达式：
_crtBreakAlloc
如果要使用 CRT 库的多线程 DLL 版本（/MD 选项），那么必须包含上下文操作符，像这样：
{,,msvcrtd.dll}_crtBreakAlloc
现在按下回车键，调试器将计算该值并把结果放入 Value 栏。如果没有在内存分配点设置任何断点，该值将为 –1。
用你想要在其位置中断的内存分配的分配序号替换 Value 栏中的值。例如输入 45。这样就会在分配序号为 45 的地方中断。
在所感兴趣的内存分配处设置断点后，可以继续调试。这时，运行程序时一定要小心，要保证内存块分配的顺序不会改变。当程序在指定的内存分配处中断时，可以查看 Call Stack（调用堆栈）窗口和其它调试器信息以确定分配内存时的情况。如果必要，可以从该点继续执行程序，以查看对象发生了什么情况，或许可以确定未正确释放对象的原因。
尽管通常在调试器中设置内存分配断点更方便，但如果愿意，也可在代码中设置这些断点。为了在代码中设置一个内存分配断点，可以增加这样一行（对于第四十五个内存分配）：
_crtBreakAlloc = 45;
你还可以使用有相同效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(45);
如何比较内存状态？
定位内存泄漏的另一个方法就是在关键点获取应用程序内存状态的快照。CRT 库提供了一个结构类型 _CrtMemState。你可以用它来存储内存状态的快照：
_CrtMemState s1, s2, s3;
若要获取给定点的内存状态快照，可以向 _CrtMemCheckpoint 函数传递一个 _CrtMemState 结构。该函数用当前内存状态的快照填充此结构：
_CrtMemCheckpoint( &s1 );
通过向 _CrtMemDumpStatistics 函数传递 _CrtMemState 结构，可以在任意地方 dump 该结构的内容：
_CrtMemDumpStatistics( &s1 );
该函数输出如下格式的 dump 内存分配信息：
0 bytes in 0 Free Blocks.75 bytes in 3 Normal Blocks.5037 bytes in 41 CRT Blocks.0 bytes in 0 Ignore Blocks.0 bytes in 0 Client Blocks.Largest number used: 5308 bytes.Total allocations: 7559 bytes.
若要确定某段代码中是否发生了内存泄漏，可以通过获取该段代码之前和之后的内存状态快照，然后使用 _CrtMemDifference 比较这两个状态：
_CrtMemCheckpoint( &s1 );// 获取第一个内存状态快照// 在这里进行内存分配_CrtMemCheckpoint( &s2 );// 获取第二个内存状态快照// 比较两个内存快照的差异if ( _CrtMemDifference( &s3, &s1, &s2) ) _CrtMemDumpStatistics( &s3 );// dump 差异结果
顾名思义，_CrtMemDifference 比较两个内存状态（前两个参数），生成这两个状态之间差异的结果（第三个参数）。在程序的开始和结尾放置 _CrtMemCheckpoint 调用，并使用 _CrtMemDifference 比较结果，是检查内存泄漏的另一种方法。如果检测到泄漏，则可以使用 _CrtMemCheckpoint 调用通过二进制搜索技术来分割程序和定位泄漏。
结论
尽管 VC ++ 具有一套专门调试 MFC 应用程序的机制，但本文上述讨论的内存分配很简单，没有涉及到 MFC 对象，所以这些内容同样也适用于 MFC 程序。在 MSDN 库中可以找到很多有关 VC++ 调试方面的资料，如果你能善用 MSDN 库，相信用不了多少时间你就有可能成为调试高手。
C++内存管理之一（检测内存泄露）
VC内存检测 2009-10-26 20:02 阅读36 评论0
字号： 大 中 小
本文来自http://blog.csdn.net/zxcred
C++程序的复杂性很大一部分在于他的内存管理，没有C#那样的垃圾回收机制，内存管理对初学者来说很困难。经常会出现内存泄露的情况。那么我们写程序如何避免内存泄露呢？首先我们需要知道程序有没有内存泄露，然后定位到底是哪行代码出现内存泄露了，这样才能将其修复。
本文描述了如何检测内存泄露。最主要的是纯C，C++的程序如何检测内存泄露。
现在有很多专业的检测工具，比如比较有名的BoundsCheck, 但是这类工具也有他的缺点，我认为首先BoundsCheck是商业软件，呵呵。然后呢需要安装，使用起来不太方便。因为我们检测的时候不一定经常会启动他来检测。这样经常会积累很多问题，那时要解决就麻烦了。最好就是从开始编码，一步一步的都能随时提醒我们内存泄露。我们编程序会经常调试，假如能在每次调试程序的时候都能自动检测内存泄露就好了。
一. 在 MFC 中检测内存泄漏
假如是用MFC的程序的话，很简单。默认的就有内存泄露检测的功能。
我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细观察,发现在每个CPP文件中,都有下面的代码:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
DEBUG_NEW 这个宏定义在afx.h文件中，就是它帮助我们定位内存泄漏。
在含有以上代码的cpp文件中分配内存后假如没有删除，那么停止程序的时候，VisualStudio的Output窗口就会显示如下的信息了：
Detected memory leaks!
Dumping objects ->
d:\code\mfctest\mfctest.cpp(80) : {157} normal block at 0x003AF170, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
在Output窗口双击粗体字那一行，那么IDE就会打开该文件，定位到该行，很容易看出是哪出现了内存泄露。
二．检测纯C++的程序内存泄露
我试了下用VisualStudio建立的Win32 Console Application和Win32 Project项目，结果都不能检测出内存泄露。
下面一步一步来把程序的内存泄露检测的机制建立起来。
首先，我们需要知道C运行库的Debug版本提供了许多检测功能，使得我们更容易的Debug程序。在MSDN中有专门的章节讲这个，叫做Debug Routines，建议大家先看看里面的内容吧。
我们会用到里面很重要的几个函数。其中最重要的是 _CrtDumpMemoryLeaks();自己看MSDN里的帮助吧。使用这个函数，需要包含头文件crtdbg.h
该函数只在Debug版本才有用，当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“Output(输出)”窗口中显示内存泄漏信息.写段代码试验一下吧，如下：
检测内存泄露版本一：
#include "stdafx.h"
#include
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
_CrtDumpMemoryLeaks();
return 0;
}
运行后，在Output（输出）窗口，显示了如下的信息：
Detected memory leaks!
Dumping objects ->
{112} normal block at 0x003AA770, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
但是这个只是告诉我们程序有内存泄露，到底在哪泄露了一眼看不出来啊。
看我们的检测内存泄露版本二：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
_CrtDumpMemoryLeaks();
return 0;
}
该程序定义了几个宏，通过宏将Debug版本下的new给替换了，新的new记录下了调用new时的文件名和代码行.运行后，可以看到如下的结果：
Detected memory leaks!
Dumping objects ->
d:\code\consoletest\consoletest.cpp(21) : {112} client block at 0x003A38B0, subtype 0, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
呵呵，已经和MFC程序的效果一样了，但是等一等。看下如下的代码吧：
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
_CrtDumpMemoryLeaks();
delete p;
return 0;
}
运行后可以发现我们删除了指针，但是它仍然报内存泄露。所以可以想象，每调用一次new，程序内部都会将该调用记录下来，类似于有个数组记录，假如delete了，那么就将其从数组中删除，而_CrtDumpMemoryLeaks()就是把这个数组当前的状态打印出来。
所以除了在必要的时候Dump出内存信息外，最重要的就是在程序退出的时候需要掉用一次_CrtDumpMemoryLeaks();
假如程序有不止一个出口，那么我们就需要在多个地方都调用该函数。
更进一步，假如程序在类的析构函数里删除指针，怎么办？例如：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
Test() { _p = new int(); }
~Test() { delete _p; }
int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
delete p;
Test t;
_CrtDumpMemoryLeaks();
return 0;
}
可以看到析构函数在程序退出的时候才调用，明明没有内存泄露，但是这样的写法还是报了。
如何改进呢,看检测内存泄露版本三：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
Test() { _p = new int(); }
~Test() { delete _p; }
int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
int* p = new int();
delete p;
Test t;
return 0;
}
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF.
这样，该版本已经达到了MFC一样的效果了，但是我觉得光这样还不够，因为我们只是在Output窗口中输出信息，对开发人员的提醒还不明显，经常会被遗漏，而且很多人就算发现了内存泄露，但是不好修复，不会严重影响到程序外在表现，都不会修复。怎么样能让开发人员主动的修复内存泄露的问题呢？记得曾经和人配合写程序，我的函数参数有要求，不能为空，但是别人老是传空值，没办法了，只好在函数开始验证函数参数，给他assert住，这样程序运行时老是不停的弹出assert，调试程序那个烦压，最后其他程序员烦了，就把这个问题给改好了，输入参数就正确了。所以我觉得咱要让程序员主动去做一件事，首先要让他觉得做这个事是能减轻自己负担，让自己工作轻松的。呵呵，那咱们也这样，当程序退出时，检测到内存泄露就让程序提示出来。
看检测内存泄露版本四：
#include "stdafx.h"
#include
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
void Exit()
{
int i = _CrtDumpMemoryLeaks();
assert( i == 0);
}
int _tmain(int argc, _TCHAR* argv[])
{
atexit(Exit);
int* p = new int();
return 0;
}
该版本会在程序退出时检查内存泄露，假如存在就会弹出提示对话框.
atexit(Exit);设置了在程序退出时执行Exit()函数。
Exit()函数中,假如存在内存泄露，_CrtDumpMemoryLeaks()会返回非0值，就会被assert住了。
到这个版本已经达到可以使用的程度了。但是我们还可以做些改进，因为真要准确的检测到代码中所有的内存泄露，需要把代码中的#define……拷贝到所有使用new的文件中。不可能每个文件都拷贝这么多代码，所以我们可以将他提取出来，放在一个文件中，比如我是放在KDetectMemoryLeak.h中，该文件内容如下：
#pragma once
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
然后将KDetectMemoryLeak.h包含在项目的通用文件中，例如用VS建的项目就将其包含在stdafx.h中。或者我自己建的一个Common.h文件中，该文件包含一些通用的，基本所有文件都会用到的代码东东。
好了，到现在，检测内存泄露总算完成了，而且他还能定位到到底是代码中哪个文件，哪行出现了内存泄露。下一篇文章将会讲些实际遇到的一些问题，例如只知道有内存泄露，但是不知道到底内存泄露的具体位置，如何利用内存断点等技术来定位内存泄露的位置啊，最后会从代码的角度讲下，怎么样才能避免内存泄露吧。
Detected memory leaks!
Dumping objects ->
c:\my.data\my.codes\memleak\memleak\memleak.cpp(34) : {126} normal block at 0x00A321A0, 4 bytes long.
Data: < > 01 00 00 00
Object dump complete. 编译器是怎么知道我们写的代码有内存泄露并能精确到文件、行号的呢？事实上也并不是所有情况都能精确到文件、行号，看看下面这种情况：
Detected memory leaks!
Dumping objects ->
First-chance exception at 0x75c739e5 (kernel32.dll) in MemLeak.exe:
0xC0000005: Access violation reading location 0x711af9f4.
#File Error#(62) : {137} normal block at 0x00A721A0, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete. 虽然检测出了内存泄露，但我们只能知道内存地址、行号，文件名是#File Error#，而且还伴随着内存非法访问的异常。这个异常看似是MFC在检测内存泄露的时候产生的。 下面我们从C++内存分配与回收的两个操作符new, delete一步步分析C++内存管理以及MFC内存泄露检测机制。所有这些都是针对Debug版本的，最后我们再看看Release版本的情况。
一、内存分配操作符new 新建一个MFC应用程序，无论是Win32 Console Application + MFC Support，还是MFC Application或者是MFC DLL。编译器为我们生成的代码最前面，在#include下面都会有下面这三行代码：
#ifdef _DEBUG
#define new DEBUG_NEW
#endif 这三句话的意思是，如果是Debug版本，那么将new操作符定义为DEBUG_NEW。在afx.h中有对DEBUG_NEW的定义：
// Memory tracking allocation
void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine);
#define DEBUG_NEW new(THIS_FILE, __LINE__) 看来MFC是重新定义了一个new操作符，并把文件名、行号调试信息传给了new。下面是这个new操作符调用的其它函数。可见是按照MFC -> C++ -> C -> Win32 API的流程分配的内存：
DEBUG_NEW
-> void* __cdecl operator new(size_t nSize, LPCSTR lpszFileName, int nLine) afxmem.cpp
-> void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine) afxmem.cpp
-> extern "C" _CRTIMP void* __cdecl _malloc_dbg(…) dbgheap.c
-> extern "C" void* __cdecl _nh_malloc_dbg(…) dbgheap.c
-> extern "C" static void * __cdecl _nh_malloc_dbg_impl(…) dbgheap.c
-> extern "C" static void * __cdecl _heap_alloc_dbg_impl(…) dbgheap.c
-> __forceinline void * __cdecl _heap_alloc (size_t size) malloc.c
-> LPVOID WINAPI HeapAlloc(…); winbase.h二、内存回收操作符delete MFC并没有重新定义delete操作符，因为所有调试信息已经传给了new操作符。delete操作符只要依然按照MFC -> C++ -> C -> Win32 API的流程将之前分配的内存释放掉就可以了：
operator delete
-> class CCRTAllocator::static void Free(void* p) throw() atlalloc.h
-> extern "C" _CRTIMP void __cdecl _free_dbg(void * pUserData, int nBlockUse) dbgheap.c
-> extern "C" void __cdecl _free_dbg_nolock(void * pUserData, int nBlockUse) dbgheap.c
-> void __cdecl _free_base (void * pBlock) free.c
-> BOOL WINAPI HeapFree(…); winbase.h三、C++内存链 内存链是MFC检测内存泄露的基础，当我们每new一块内存，_heap_alloc_dbg_impl就会把这块内存加入内存链，当我们delete一块内存，_free_dbg_nolock就会把这块内存从内存链中删除。VC的实现是使用了一个双向链表。每一个节点的结构定义如下：
typedef struct _CrtMemBlockHeader
{
struct _CrtMemBlockHeader * pBlockHeaderNext; // 下一个节点指针
struct _CrtMemBlockHeader * pBlockHeaderPrev; // 前一个节点指针
char * szFileName; // 调用new的文件名
int nLine; // 调用new的行号
size_t nDataSize; // 调用new分配内存大小
int nBlockUse; // 本块内存使用目的
long lRequest; // 请求编号
unsigned char gap[nNoMansLandSize]; // 内存前面的空白
/* followed by:
* unsigned char data[nDataSize]; // 真正的内存
* unsigned char anotherGap[nNoMansLandSize]; // 内存后面的空白
*/
} _CrtMemBlockHeader; 结构体中有几个成员可能需要解释一下。nBlockUse表示本块内存的用途，一般取值为_NORMAL_BLOCK。lRequest表示请求内存的编号，初始值为1，每请求一次，该值加1。我们在输出窗口看到的normal block就表示nBlockUse=_NORMAL_BLOCK， {137} 就是lRequest的值。data是真正返回给我们的指针，编译器在data前后用gap, anotherGap将数据保护起来并赋予特殊的值，以检测我们对指针操作是否越界。这些空白区域内存大小为#define nNoMansLandSize 4。data同样被赋予特殊的值，特殊值总共有四种：
static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */
static unsigned char _bAlignLandFill = 0xED; /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill = 0xDD; /* fill free objects with this */
static unsigned char _bCleanLandFill = 0xCD; /* fill new objects with this */比如说我们new了一个int对象，int* p = new int；那么上面这个结构体内容如下：
+------------------------------------------------------------------------------+
| pBlockHeaderNext | …… | gap: FDFDFDFD | p: CDCDCDCD | anotherGap: FDFDFDFD |
+------------------------------------------------------------------------------+ 比如说我们内存访问越界了：*(p+1) = 0，那么在delete这个指针的时候，_free_dbg_nolock会对gap, anotherGap的值进行检查，发现不等于_bNoMansLandFill，就报错。如果我们写*(p+1) = 0xFDFDFDFD，那么就把编译器骗了，编译器认为内存访问并没有越界。当我们delete一块内存的时候，这块内存会被用_bDeadLandFill填充。如果我们new了多个对象，那么这些对象就链接再了一起，例如：
int* pB = new int;
int* pA = new int;内存布局如下：
+--------------------------------------------------------------------------+
| +--------------------------+ +--------------------------+ |
+-> | pHead = pBlockHeaderNext | -----------> | pBlockHeaderNext = NULL | |
|--------------------------| |--------------------------| |
| pBlockHeaderPrev = NULL | | pBlockHeaderPrev ->-|-+
|--------------------------| |--------------------------|
| ...... | | ...... |
|--------------------------| |--------------------------|
|gap: FDFDFDFD | |gap: FDFDFDFD |
|--------------------------| |--------------------------|
|pA: CDCDCDCD | |pB: CDCDCDCD |
|--------------------------| |--------------------------|
|anotherGap: FDFDFDFD | |anotherGap: FDFDFDFD |
+--------------------------+ +--------------------------+ 知道了内存块的布局，我们甚至可以通过一个指针，打印出当前new过的所有对象内存地址及大小。为了验证上述内容的正确性，我们不妨写一个简单的验证程序：
int* pB = new int(2);
int* pA = new int(1);cout << "*pA = " << *pA << ", *pB = " << *pB << endl; // *pA = 1, *pB = 2*((int*)(*(pA - 8)) + 8) = 1;
*((int*)(*(pB - 7)) + 8) = 2;cout << "*pA = " << *pA << ", *pB = " << *pB << endl; // *pA = 2, *pB = 1delete pA;
delete pB;四、内存泄露检测机制 MFC正是因为有了内存链，才可以检测出哪些内存还没有被释放。在程序退出的时候，dbgheap.c中的extern "C" _CRTIMP int __cdecl _CrtDumpMemoryLeaks(void)函数会被调用，然后遍历当前的内存链，看看还有哪些内存没有被释放，然后打印出内存泄露的信息。原理很简单，这里不再赘述。那么为什么有的情况下我们无法通过输出的信息定位到具体泄露的文件呢？为什么有的时候会显示#File Error#？看看上面提到的结构体中文件名的保存char * szFileName，仅仅保存了一个指向文件名的指针而已。这个文件名是作为一个字符串，保存在.exe或.dll的.rdata中的。如果在.exe文件退出的时候，我们显式加载的.dll文件已经被我们卸载了，并且在该.dll文件内存存在内存泄露的话，虽然_CrtDumpMemoryLeaks会尝试读取并显示文件名，但szFileName指针指向的内存空间已经是无效的了。_CrtDumpMemoryLeaks在读取文件名之前会先调用API函数IsBadReadPtr判断该指针是否有效。如果已经无效则显示#File Error#。本文最开始所提到的异常，正是由IsBadReadPtr导致的。
五、Release版本 对于Release版本，就没有上面提到的内存链了。对于new和delete的调用将会被直接转到malloc.c和free.c。因为没有内存链，没有多余的保护数据填充，没有内存越界检测机制，所以有些时候Debug版本会崩溃，但是Release版本却没有。这并不代表代码没有问题，而是内存非法访问更难发现了，当Release版本崩溃的时候，问题也更难定位了。
上述内存泄露检测、内存越界访问检测的原理很简单，但并不能查出所有内存非法访问。所以永远不要乱用指针，然后把所有对指针的判断都用try{}catch{}规避。因为并不是所有指针非法访问都能catch到，即使catch到了，内存也可能已经被写坏了。
关于MFC下检查和消除内存泄露的技巧
作者：freepublic
摘要
本文分析了Windows环境使用MFC调试内存泄露的技术，介绍了在Windows环境下用VC++查找，定位和消除内存泄露的方法技巧。
关键词：VC++；CRT 调试堆函数；试探法。
编译环境
VC++6.0
技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include
#include
注意 #include 语句必须采用上文所示顺序。如果更改了顺序，所使用的函数可能无法正确工作。
通过包括 crtdbg.h，将 malloc 和 free 函数映射到其“Debug”版本_malloc_dbg 和_free_dbg，这些函数将跟踪内存分配和释放。此映射只在调试版本（在其中定义了 _DEBUG）中发生。发布版本使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。并非绝对需要该语句，但如果没有该语句，内存泄漏转储包含的有用信息将较少。
在添加了上面所示语句之后，可以通过在程序中包括以下语句来转储内存泄漏信息：
_CrtDumpMemoryLeaks();
当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。内存泄漏信息如下所示：
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：
Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是：
内存分配编号（在大括号内）。
块类型（普通、客户端或 CRT）。
十六进制形式的内存位置。
以字节为单位的块大小。
前 16 字节的内容（亦为十六进制）。
定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。文件名后括号中的数字（本示例中为 20）是该文件内的行号。
转到源文件中分配内存的行
在"输出"窗口中双击包含文件名和行号的行。
-或-
在"输出"窗口中选择包含文件名和行号的行，然后按 F4 键。
_CrtSetDbgFlag
如果程序总在同一位置退出，则调用 _CrtDumpMemoryLeaks 足够方便，但如果程序可以从多个位置退出该怎么办呢？不要在每个可能的出口放置一个对 _CrtDumpMemoryLeaks 的调用，可以在程序开始包括以下调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如上所示。
说明
在VC++6.0的环境下，不再需要额外的添加
#define CRTDBG_MAP_ALLOC
#include
#include
只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现
Detected memory leaks!
Dumping objects ->
就有内存泄露。
确定内存泄露的地方
根据内存泄露的报告，有两种消除的方法：
第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20)
就是源文件名称和行号。
第二种比较麻烦，就是不能映射到源文件的，只有内存分配块号。
Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
这种情况我采用一种"试探法"。由于内存分配的块号不是固定不变的，而是每次运行都是变化的，所以跟踪起来很麻烦。但是我发现虽然内存分配的块号是变化的，但是变化的块号却总是那几个，也就是说多运行几次，内存分配的块号很可能会重复。因此这就是"试探法"的基础。
1. 先在调试状态下运行几次程序，观察内存分配的块号是哪几个值；
2. 选择出现次数最多的块号来设断点，在代码中设置内存分配断点： 添加如下一行（对于第 18 个内存分配）：
_crtBreakAlloc = 18;
或者，可以使用具有同样效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(18);
3. 在调试状态下运行序，在断点停下时，打开"调用堆栈"窗口，找到对应的源代码处；
4. 退出程序，观察"输出窗口"的内存泄露报告，看实际内存分配的块号是不是和预设值相同，如果相同，就找到了；如果不同，就重复步骤3，直到相同。
5. 最后就是根据具体情况，在适当的位置释放所分配的内存。
(全文完)
（转完整）VC内存泄露检测
2009-10-28 21:15
最近看了周星星 Blog 中的一篇文章：“VC++6.0中内存泄漏检测”，受益匪浅，便运行其例子代码想看看 Output 窗口中的输出结果，可惜怎么弄其输出都不是预期的东西，郁闷了半天，便到水坛里找到周星星，请求他指点一、二，然而未果。没有办法，最后我一头栽进 MSDN 库狂搜了一把，功夫不负有心人，我搜出很多有关这方面的资料，没过多久我便基本上就找到了答案......
首先，检测内存泄漏的基本工具是调试器和 CRT 调试堆函数。为了使用调试堆函数，必须在要检测内存泄漏和调试的程序中添加下面的语句：
#define _CRTDBG_MAP_ALLOC #include
MSDN 如是说：“必须保证上面声明的顺序，如果改变了顺序，可能不能正常工作。”至于这是为什么，我们不得而知。MS 的老大们经常这样故弄玄虚。
针对非 MFC 程序，再加上周星星的头文件：（1）debug_new.h，当然如果不加这一句，也能检测出内存泄漏，但是你无法确定在哪个源程序文件中发生泄漏；（2）我们来模拟下MFC做的事情。看下例：
inline void EnableMemLeakCheck()
{
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}
#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif
void main()
{
EnableMemLeakCheck();
int* leak = new int[10];
}
。Output 输出只告诉你在 crtsdb.h 中的某个地方有内存泄漏。我测试时 REG_DEBUG_NEW 没有起作用。加不加这个宏都可以检测出发生内存分配泄漏的文件。
其次，一旦添加了上面的声明，你就可以通过在程序中加入下面的代码来报告内存泄漏信息了：
_CrtDumpMemoryLeaks(); 这就这么简单。我在周星星的例子代码中加入这些机关后，在 VC++ 调试会话（按 F5 调试运行） Output 窗口的 Debug 页便看到了预期的内存泄漏 dump。该 dump 形式如下：
Detected memory leaks! Dumping objects -> c:\Program Files\...\include\crtdbg.h(552) : {45} normal block at 0x00441BA0, 2 bytes long. Data:
更具体的细节请参考本文附带的源代码文件。
下面是我看过 MSDN 资料后，针对“如何使用 CRT 调试功能来检测内存泄漏？”的问题进行了一番编译和整理，希望对大家有用。如果你的英文很棒，那就不用往下看了，建议直接去读 MSDN 库中的技术原文。
C/C++ 编程语言的最强大功能之一便是其动态分配和释放内存，但是中国有句古话：“最大的长处也可能成为最大的弱点”，那么 C/C++ 应用程序正好印证了这句话。在 C/C++ 应用程序开发过程中，动态分配的内存处理不当是最常见的问题。其中，最难捉摸也最难检测的错误之一就是内存泄漏，即未能正确释放以前分配的内存的错误。偶尔发生的少量内存泄漏可能不会引起我们的注意，但泄漏大量内存的程序或泄漏日益增多的程序可能会表现出各种 各样的征兆：从性能不良（并且逐渐降低）到内存完全耗尽。更糟的是，泄漏的程序可能会用掉太多内存，导致另外一个程序垮掉，而使用户无从查找问题的真正根源。此外，即使无害的内存泄漏也可能殃及池鱼。
幸运的是，Visual Studio 调试器和 C 运行时 (CRT) 库为我们提供了检测和识别内存泄漏的有效方法。下面请和我一起分享收获——如何使用 CRT 调试功能来检测内存泄漏？
如何启用内存泄漏检测机制？
使用 _CrtSetDbgFlag
设置 CRT 报告模式
解释内存块类型
如何在内存分配序号处设置断点？
如何比较内存状态？
结论
如何启用内存泄漏检测机制？
VC++ IDE 的默认状态是没有启用内存泄漏检测机制的，也就是说即使某段代码有内存泄漏，调试会话的 Output 窗口的 Debug 页不会输出有关内存泄漏信息。你必须设定两个最基本的机关来启用内存泄漏检测机制。
一是使用调试堆函数：
#define _CRTDBG_MAP_ALLOC #include
注意：#include 语句的顺序。如果更改此顺序，所使用的函数可能无法正确工作。
通过包含 crtdbg.h 头文件，可以将 malloc 和 free 函数映射到其“调试”版本 _malloc_dbg 和 _free_dbg，这些函数会跟踪内存分配和释放。此映射只在调试（Debug）版本（也就是要定义 _DEBUG）中有效。发行版本（Release）使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基础版本映射到对应的“调试”版本。该语句不是必须的，但如果没有该语句，那么有关内存泄漏的信息会不全。
二是在需要检测内存泄漏的地方添加下面这条语句来输出内存泄漏信息：
_CrtDumpMemoryLeaks(); 当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在 Output 窗口的 Debug 页中显示内存泄漏信息。比如：
Detected memory leaks!Dumping objects ->C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long.Data:
如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏的输出是这样的：
Detected memory leaks!Dumping objects ->{45} normal block at 0x00441BA0, 2 bytes long.Data:
xx}：花括弧内的数字是内存分配序号，本文例子中是 {45}，{44}，{43}；block：内存块的类型，常用的有三种：normal（普通）、client（客户端）或 CRT（运行时）；本文例子中是：normal block； 用十六进制格式表示的内存位置，如：at 0x00441BA0 等；以字节为单位表示的内存块的大小，如：32 bytes long； 前 16 字节的内容（也是用十六进制格式表示），如：Data:
仔细观察不难发现，如果定义了 _CRTDBG_MAP_ALLOC ，那么在内存分配序号前面还会显示在其中分配泄漏内存的文件名，以及文件名后括号中的数字表示发生泄漏的代码行号，比如：
C:\Temp\memleak\memleak.cpp(15) 双击 Output 窗口中此文件名所在的输出行，便可跳到源程序文件分配该内存的代码行（也可以选中该行，然后按 F4，效果一样） ，这样一来我们就很容易定位内存泄漏是在哪里发生的了，因此，_CRTDBG_MAP_ALLOC 的作用显而易见。
使用 _CrtSetDbgFlag
如果程序只有一个出口，那么调用 _CrtDumpMemoryLeaks 的位置是很容易选择的。但是，如果程序可能会在多个地方退出该怎么办呢？在每一个可能的出口处调用 _CrtDumpMemoryLeaks 肯定是不可取的，那么这时可以在程序开始处包含下面的调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
这条语句无论程序在什么地方退出都会自动调用 _CrtDumpMemoryLeaks。注意：这里必须同时设置两个位域标志：_CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF。
设置 CRT 报告模式
默认情况下，_CrtDumpMemoryLeaks 将内存泄漏信息 dump 到 Output 窗口的 Debug 页， 如果你想将这个输出定向到别的地方，可以使用 _CrtSetReportMode 进行重置。如果你使用某个库，它可能将输出定向到另一位置。此时，只要使用以下语句将输出位置设回 Output 窗口即可：
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );
有关使用 _CrtSetReportMode 的详细信息，请参考 MSDN 库关于 _CrtSetReportMode 的描述。
解释内存块类型
前面已经说过，内存泄漏报告中把每一块泄漏的内存分为 normal（普通块）、client（客户端块）和 CRT 块。事实上，需要留心和注意的也就是 normal 和 client，即普通块和客户端块。
normal block（普通块）：这是由你的程序分配的内存。
client block（客户块）：这是一种特殊类型的内存块，专门用于 MFC 程序中需要析构函数的对象。MFC new 操作符视具体情况既可以为所创建的对象建立普通块，也可以为之建立客户块。
CRT block（CRT 块）：是由 C RunTime Library 供自己使用而分配的内存块。由 CRT 库自己来管理这些内存的分配与释放，我们一般不会在内存泄漏报告中发现 CRT 内存泄漏，除非程序发生了严重的错误（例如 CRT 库崩溃）。
除了上述的类型外，还有下面这两种类型的内存块，它们不会出现在内存泄漏报告中：
free block（空闲块）：已经被释放(free)的内存块。
Ignore block（忽略块）：这是程序员显式声明过不要在内存泄漏报告中出现的内存块。
如何在内存分配序号处设置断点？
在内存泄漏报告中，的文件名和行号可告诉分配泄漏的内存的代码位置，但仅仅依赖这些信息来了解完整的泄漏原因是不够的。因为一个程序在运行时，一段分配内存的代码可能会被调用很多次，只要有一次调用后没有释放内存就会导致内存泄漏。为了确定是哪些内存没有被释放，不仅要知道泄漏的内存是在哪里分配的，还要知道泄漏产生的条件。这时内存分配序号就显得特别有用——这个序号就是文件名和行号之后的花括弧里的那个数字。
例如，在本文例子代码的输出信息中，“45”是内存分配序号，意思是泄漏的内存是你程序中分配的第四十五个内存块：
Detected memory leaks!Dumping objects ->C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long.Data:
CRT 库对程序运行期间分配的所有内存块进行计数，包括由 CRT 库自己分配的内存和其它库（如 MFC）分配的内存。因此，分配序号为 N 的对象即为程序中分配的第 N 个对象，但不一定是代码分配的第 N 个对象。（大多数情况下并非如此。）
这样的话，你便可以利用分配序号在分配内存的位置设置一个断点。方法是在程序起始附近设置一个位置断点。当程序在该点中断时，可以从 QuickWatch（快速监视）对话框或 Watch（监视）窗口设置一个内存分配断点：
例如，在 Watch 窗口中，在 Name 栏键入下面的表达式：
_crtBreakAlloc
如果要使用 CRT 库的多线程 DLL 版本（/MD 选项），那么必须包含上下文操作符，像这样：
{,,msvcrtd.dll}_crtBreakAlloc
现在按下回车键，调试器将计算该值并把结果放入 Value 栏。如果没有在内存分配点设置任何断点，该值将为 –1。
用你想要在其位置中断的内存分配的分配序号替换 Value 栏中的值。例如输入 45。这样就会在分配序号为 45 的地方中断。
在所感兴趣的内存分配处设置断点后，可以继续调试。这时，运行程序时一定要小心，要保证内存块分配的顺序不会改变。当程序在指定的内存分配处中断时，可以查看 Call Stack（调用堆栈）窗口和其它调试器信息以确定分配内存时的情况。如果必要，可以从该点继续执行程序，以查看对象发生了什么情况，或许可以确定未正确释放对象的原因。
尽管通常在调试器中设置内存分配断点更方便，但如果愿意，也可在代码中设置这些断点。为了在代码中设置一个内存分配断点，可以增加这样一行（对于第四十五个内存分配）：
_crtBreakAlloc = 45;
你还可以使用有相同效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(45);
如何比较内存状态？
定位内存泄漏的另一个方法就是在关键点获取应用程序内存状态的快照。CRT 库提供了一个结构类型 _CrtMemState。你可以用它来存储内存状态的快照：
_CrtMemState s1, s2, s3;
若要获取给定点的内存状态快照，可以向 _CrtMemCheckpoint 函数传递一个 _CrtMemState 结构。该函数用当前内存状态的快照填充此结构：
_CrtMemCheckpoint( &s1 );
通过向 _CrtMemDumpStatistics 函数传递 _CrtMemState 结构，可以在任意地方 dump 该结构的内容：
_CrtMemDumpStatistics( &s1 );
该函数输出如下格式的 dump 内存分配信息：
0 bytes in 0 Free Blocks.75 bytes in 3 Normal Blocks.5037 bytes in 41 CRT Blocks.0 bytes in 0 Ignore Blocks.0 bytes in 0 Client Blocks.Largest number used: 5308 bytes.Total allocations: 7559 bytes.
若要确定某段代码中是否发生了内存泄漏，可以通过获取该段代码之前和之后的内存状态快照，然后使用 _CrtMemDifference 比较这两个状态：
_CrtMemCheckpoint( &s1 );// 获取第一个内存状态快照// 在这里进行内存分配_CrtMemCheckpoint( &s2 );// 获取第二个内存状态快照// 比较两个内存快照的差异if ( _CrtMemDifference( &s3, &s1, &s2) ) _CrtMemDumpStatistics( &s3 );// dump 差异结果
顾名思义，_CrtMemDifference 比较两个内存状态（前两个参数），生成这两个状态之间差异的结果（第三个参数）。在程序的开始和结尾放置 _CrtMemCheckpoint 调用，并使用 _CrtMemDifference 比较结果，是检查内存泄漏的另一种方法。如果检测到泄漏，则可以使用 _CrtMemCheckpoint 调用通过二进制搜索技术来分割程序和定位泄漏。
结论
尽管 VC ++ 具有一套专门调试 MFC 应用程序的机制，但本文上述讨论的内存分配很简单，没有涉及到 MFC 对象，所以这些内容同样也适用于 MFC 程序。在 MSDN 库中可以找到很多有关 VC++ 调试方面的资料，如果你能善用 MSDN 库，相信用不了多少时间你就有可能成为调试高手。
C++内存管理之一（检测内存泄露）
VC内存检测 2009-10-26 20:02 阅读36 评论0
字号： 大 中 小
本文来自http://blog.csdn.net/zxcred
C++程序的复杂性很大一部分在于他的内存管理，没有C#那样的垃圾回收机制，内存管理对初学者来说很困难。经常会出现内存泄露的情况。那么我们写程序如何避免内存泄露呢？首先我们需要知道程序有没有内存泄露，然后定位到底是哪行代码出现内存泄露了，这样才能将其修复。
本文描述了如何检测内存泄露。最主要的是纯C，C++的程序如何检测内存泄露。
现在有很多专业的检测工具，比如比较有名的BoundsCheck, 但是这类工具也有他的缺点，我认为首先BoundsCheck是商业软件，呵呵。然后呢需要安装，使用起来不太方便。因为我们检测的时候不一定经常会启动他来检测。这样经常会积累很多问题，那时要解决就麻烦了。最好就是从开始编码，一步一步的都能随时提醒我们内存泄露。我们编程序会经常调试，假如能在每次调试程序的时候都能自动检测内存泄露就好了。
一. 在 MFC 中检测内存泄漏
假如是用MFC的程序的话，很简单。默认的就有内存泄露检测的功能。
我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细观察,发现在每个CPP文件中,都有下面的代码:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
DEBUG_NEW 这个宏定义在afx.h文件中，就是它帮助我们定位内存泄漏。
在含有以上代码的cpp文件中分配内存后假如没有删除，那么停止程序的时候，VisualStudio的Output窗口就会显示如下的信息了：
Detected memory leaks!
Dumping objects ->
d:\code\mfctest\mfctest.cpp(80) : {157} normal block at 0x003AF170, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
在Output窗口双击粗体字那一行，那么IDE就会打开该文件，定位到该行，很容易看出是哪出现了内存泄露。
二．检测纯C++的程序内存泄露
我试了下用VisualStudio建立的Win32 Console Application和Win32 Project项目，结果都不能检测出内存泄露。
下面一步一步来把程序的内存泄露检测的机制建立起来。
首先，我们需要知道C运行库的Debug版本提供了许多检测功能，使得我们更容易的Debug程序。在MSDN中有专门的章节讲这个，叫做Debug Routines，建议大家先看看里面的内容吧。
我们会用到里面很重要的几个函数。其中最重要的是 _CrtDumpMemoryLeaks();自己看MSDN里的帮助吧。使用这个函数，需要包含头文件crtdbg.h
该函数只在Debug版本才有用，当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“Output(输出)”窗口中显示内存泄漏信息.写段代码试验一下吧，如下：
检测内存泄露版本一：
#include "stdafx.h"
#include
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
_CrtDumpMemoryLeaks();
return 0;
}
运行后，在Output（输出）窗口，显示了如下的信息：
Detected memory leaks!
Dumping objects ->
{112} normal block at 0x003AA770, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
但是这个只是告诉我们程序有内存泄露，到底在哪泄露了一眼看不出来啊。
看我们的检测内存泄露版本二：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
_CrtDumpMemoryLeaks();
return 0;
}
该程序定义了几个宏，通过宏将Debug版本下的new给替换了，新的new记录下了调用new时的文件名和代码行.运行后，可以看到如下的结果：
Detected memory leaks!
Dumping objects ->
d:\code\consoletest\consoletest.cpp(21) : {112} client block at 0x003A38B0, subtype 0, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
呵呵，已经和MFC程序的效果一样了，但是等一等。看下如下的代码吧：
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
_CrtDumpMemoryLeaks();
delete p;
return 0;
}
运行后可以发现我们删除了指针，但是它仍然报内存泄露。所以可以想象，每调用一次new，程序内部都会将该调用记录下来，类似于有个数组记录，假如delete了，那么就将其从数组中删除，而_CrtDumpMemoryLeaks()就是把这个数组当前的状态打印出来。
所以除了在必要的时候Dump出内存信息外，最重要的就是在程序退出的时候需要掉用一次_CrtDumpMemoryLeaks();
假如程序有不止一个出口，那么我们就需要在多个地方都调用该函数。
更进一步，假如程序在类的析构函数里删除指针，怎么办？例如：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
Test() { _p = new int(); }
~Test() { delete _p; }
int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
int* p = new int();
delete p;
Test t;
_CrtDumpMemoryLeaks();
return 0;
}
可以看到析构函数在程序退出的时候才调用，明明没有内存泄露，但是这样的写法还是报了。
如何改进呢,看检测内存泄露版本三：
#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
Test() { _p = new int(); }
~Test() { delete _p; }
int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
int* p = new int();
delete p;
Test t;
return 0;
}
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF.
这样，该版本已经达到了MFC一样的效果了，但是我觉得光这样还不够，因为我们只是在Output窗口中输出信息，对开发人员的提醒还不明显，经常会被遗漏，而且很多人就算发现了内存泄露，但是不好修复，不会严重影响到程序外在表现，都不会修复。怎么样能让开发人员主动的修复内存泄露的问题呢？记得曾经和人配合写程序，我的函数参数有要求，不能为空，但是别人老是传空值，没办法了，只好在函数开始验证函数参数，给他assert住，这样程序运行时老是不停的弹出assert，调试程序那个烦压，最后其他程序员烦了，就把这个问题给改好了，输入参数就正确了。所以我觉得咱要让程序员主动去做一件事，首先要让他觉得做这个事是能减轻自己负担，让自己工作轻松的。呵呵，那咱们也这样，当程序退出时，检测到内存泄露就让程序提示出来。
看检测内存泄露版本四：
#include "stdafx.h"
#include
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
void Exit()
{
int i = _CrtDumpMemoryLeaks();
assert( i == 0);
}
int _tmain(int argc, _TCHAR* argv[])
{
atexit(Exit);
int* p = new int();
return 0;
}
该版本会在程序退出时检查内存泄露，假如存在就会弹出提示对话框.
atexit(Exit);设置了在程序退出时执行Exit()函数。
Exit()函数中,假如存在内存泄露，_CrtDumpMemoryLeaks()会返回非0值，就会被assert住了。
到这个版本已经达到可以使用的程度了。但是我们还可以做些改进，因为真要准确的检测到代码中所有的内存泄露，需要把代码中的#define……拷贝到所有使用new的文件中。不可能每个文件都拷贝这么多代码，所以我们可以将他提取出来，放在一个文件中，比如我是放在KDetectMemoryLeak.h中，该文件内容如下：
#pragma once
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include
#include
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
然后将KDetectMemoryLeak.h包含在项目的通用文件中，例如用VS建的项目就将其包含在stdafx.h中。或者我自己建的一个Common.h文件中，该文件包含一些通用的，基本所有文件都会用到的代码东东。
好了，到现在，检测内存泄露总算完成了，而且他还能定位到到底是代码中哪个文件，哪行出现了内存泄露。下一篇文章将会讲些实际遇到的一些问题，例如只知道有内存泄露，但是不知道到底内存泄露的具体位置，如何利用内存断点等技术来定位内存泄露的位置啊，最后会从代码的角度讲下，怎么样才能避免内存泄露吧。