浅谈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下面都会有下面这三行代码：
_DEBUG DEBUG_NEW
这三句话的意思是，如果是Debug版本，那么将new操作符定义为DEBUG_NEW。在afx.h中有对DEBUG_NEW的定义：
* AFX_CDECL (size_t nSize, LPCSTR lpszFileName, nLine); DEBUG_NEW (THIS_FILE, __LINE__)
看来MFC是重新定义了一个new操作符，并把文件名、行号调试信息传给了new。下面是这个new操作符调用的其它函数。可见是按照MFC -> C++ -> C -> Win32 API的流程分配的内存：
DEBUG_NEW -> * (size_t nSize, LPCSTR lpszFileName, nLine) afxmem.cpp -> * (size_t nSize, nType, LPCSTR lpszFileName, nLine) afxmem.cpp -> _CRTIMP * _malloc_dbg(…) dbgheap.c -> * _nh_malloc_dbg(…) dbgheap.c -> * _nh_malloc_dbg_impl(…) dbgheap.c -> * _heap_alloc_dbg_impl(…) dbgheap.c -> void * _heap_alloc (size_t size) malloc.c -> LPVOID WINAPI HeapAlloc(…); winbase.h
二、内存回收操作符delete MFC并没有重新定义delete操作符，因为所有调试信息已经传给了new操作符。delete操作符只要依然按照MFC -> C++ -> C -> Win32 API的流程将之前分配的内存释放掉就可以了：
-> class CCRTAllocator:: Free(* p) () atlalloc.h -> _CRTIMP _free_dbg( * pUserData, nBlockUse) dbgheap.c -> _free_dbg_nolock( * pUserData, nBlockUse) dbgheap.c -> _free_base ( * pBlock) free.c -> BOOL WINAPI HeapFree(…); winbase.h
三、C++内存链 内存链是MFC检测内存泄露的基础，当我们每new一块内存，_heap_alloc_dbg_impl就会把这块内存加入内存链，当我们delete一块内存，_free_dbg_nolock就会把这块内存从内存链中删除。VC的实现是使用了一个双向链表。每一个节点的结构定义如下：
_CrtMemBlockHeader
{
_CrtMemBlockHeader * pBlockHeaderNext; _CrtMemBlockHeader * pBlockHeaderPrev; * szFileName;
nLine;
size_t nDataSize; nBlockUse; lRequest; gap[nNoMansLandSize];
} _CrtMemBlockHeader;
结构体中有几个成员可能需要解释一下。nBlockUse表示本块内存的用途，一般取值为_NORMAL_BLOCK。lRequest表示请求内存的编号，初始值为1，每请求一次，该值加1。我们在输出窗口看到的normal block就表示nBlockUse=_NORMAL_BLOCK， {137} 就是lRequest的值。data是真正返回给我们的指针，编译器在data前后用gap, anotherGap将数据保护起来并赋予特殊的值，以检测我们对指针操作是否越界。这些空白区域内存大小为#define nNoMansLandSize 4。data同样被赋予特殊的值，特殊值总共有四种：
_bNoMansLandFill = 0xFD; _bAlignLandFill = 0xED; _bDeadLandFill = 0xDD; _bCleanLandFill = 0xCD;
比如说我们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了多个对象，那么这些对象就链接再了一起，例如：
* pB = ; * pA = ;
内存布局如下：
+--------------------------------------------------------------------------+ | +--------------------------+ +--------------------------+ | +-> | pHead = pBlockHeaderNext | -----------> | pBlockHeaderNext = NULL | | |--------------------------| |--------------------------| | | pBlockHeaderPrev = NULL | | pBlockHeaderPrev ->-|-+ |--------------------------| |--------------------------| | ...... | | ...... | |--------------------------| |--------------------------| |gap: FDFDFDFD | |gap: FDFDFDFD | |--------------------------| |--------------------------| |pA: CDCDCDCD | |pB: CDCDCDCD | |--------------------------| |--------------------------| |anotherGap: FDFDFDFD | |anotherGap: FDFDFDFD | +--------------------------+ +--------------------------+
知道了内存块的布局，我们甚至可以通过一个指针，打印出当前new过的所有对象内存地址及大小。为了验证上述内容的正确性，我们不妨写一个简单的验证程序：
* pB = (2); * pA = (1);
cout << << *pA << << *pB << endl;
*((*)(*(pA - 8)) + 8) = 1; *((*)(*(pB - 7)) + 8) = 2;
cout << << *pA << << *pB << endl;
pA; 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到了，内存也可能已经被写坏了。