博文
VC6调试版本C运行库内存申请的一个bug
|||
这两天调程序，遇到一个莫名奇妙的错误，程序总是在运行很长一段时间后崩溃，但是在两台机器上显示错误提示，一台机器上显示是否调试。
很无语的调了两三天了，一直没进展，最早怀疑是内存泄露的原因，后来下载了vld一点点的调，没有内存泄露了，程序照样出问题，郁闷啊。
今天早上在这台机器上发现，每次崩溃实际上都是调用了int 3中断，于是开始研究汇编，转了半天，发现晕了，上网搜，结果发现了下面这篇文章，让我ft，竟然是vc6的调试版bug
=================================================================
VC调试版本C运行库内存申请的一个bug
遇到过一个通信方面的软件，需要长期运行，做压力测试时，高负荷连续运行一定天数时必定崩溃，而且都是在msvcrtd.dll中崩溃。负责维护的人百思不得其解，就去问微软的人，结果微软的人说这是VC6带的msvcrtd.dll的一个问题，VC2005已经没有这个问题了，请升级到新的版本。这个软件规模比较大，依赖于很多库，后台都是用VC6编译的调试版本，为了方便定位问题，没有Release版本。升级到VC2005后会不会出现别的问题，没有人敢冒这个风险，于是没有使用VC2005。
闲着没事的时候分析了一下，才发现问题其实很简单。msvcrtd.dll对每次内存申请都进行计数，当计数值达到设定的某个值时，就会调用_CrtDbgBreak()。MSDN对_CrtDbgBreak的说明是：Sets a break point on a particular line of code，其实_CrtDbgBreak在X86下只有一条指令就是int 3(0xCC)。
在dbgheap.c中定义了下面两个变量：
static long _lRequestCurr = 1; /* Current request number */
extern "C" _CRTIMP long _crtBreakAlloc = -1L; /* Break on allocation by request number */
_lRequestCurr表示当前的申请次数，_crtBreakAlloc表示当内存申请次数达到某个值时break，即调用_CrtDbgBreak。详情可参考debugheap.c中的_heap_alloc_dbg_impl函数：
lRequest = _lRequestCurr;
/* break into debugger at specific memory allocation */
if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)
_CrtDbgBreak();
VC6附带的dbgheap.c中没有添加_crtBreakAlloc != -1L的判断，而是：
if (lRequest == _crtBreakAlloc)
_CrtDbgBreak();
_lRequestCurr初始化为1，每次申请内存都加1，当_lRequestCurr为-1时在VC6的dbgheap.c中就会触发int 3导致程序退出，而在新的版本中添加了_crtBreakAlloc != -1L的判断，所以默认的情况下是不会触发int 3 退出的。
可以通过调用_CrtSetBreakAlloc设置_crtBreakAlloc的值，当我们设置了新的_crtBreakAlloc，而且_crtBreakAlloc等于_lRequestCurr时就会触发int 3。
弄清楚了问题的所在，我们就可以着手解决问题了。VC6的dbgheap.c中有两个地方判断了lRequest 是否与_crtBreakAlloc相等，相等后执行指令int 3。我们不用复杂的处理，把int 3替换为nop（0x90）指令即可。首先得到“if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)” 对应的二进制指令，用UE打开msvcrtd.dll，使用16进制编辑模式，查找得到的二进制指令，发现确实只有二处，把紧接着它们的0xCC替换为0x90，问题解决。
遇到过一个通信方面的软件，需要长期运行，做压力测试时，高负荷连续运行一定天数时必定崩溃，而且都是在msvcrtd.dll中崩溃。负责维护的人百思不得其解，就去问微软的人，结果微软的人说这是VC6带的msvcrtd.dll的一个问题，VC2005已经没有这个问题了，请升级到新的版本。这个软件规模比较大，依赖于很多库，后台都是用VC6编译的调试版本，为了方便定位问题，没有Release版本。升级到VC2005后会不会出现别的问题，没有人敢冒这个风险，于是没有使用VC2005。
闲着没事的时候分析了一下，才发现问题其实很简单。msvcrtd.dll对每次内存申请都进行计数，当计数值达到设定的某个值时，就会调用_CrtDbgBreak()。MSDN对_CrtDbgBreak的说明是：Sets a break point on a particular line of code，其实_CrtDbgBreak在X86下只有一条指令就是int 3(0xCC)。
在dbgheap.c中定义了下面两个变量：
static long _lRequestCurr = 1; /* Current request number */
extern "C" _CRTIMP long _crtBreakAlloc = -1L; /* Break on allocation by request number */
_lRequestCurr表示当前的申请次数，_crtBreakAlloc表示当内存申请次数达到某个值时break，即调用_CrtDbgBreak。详情可参考debugheap.c中的_heap_alloc_dbg_impl函数：
lRequest = _lRequestCurr;
/* break into debugger at specific memory allocation */
if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)
_CrtDbgBreak();
VC6附带的dbgheap.c中没有添加_crtBreakAlloc != -1L的判断，而是：
if (lRequest == _crtBreakAlloc)
_CrtDbgBreak();
_lRequestCurr初始化为1，每次申请内存都加1，当_lRequestCurr为-1时在VC6的dbgheap.c中就会触发int 3导致程序退出，而在新的版本中添加了_crtBreakAlloc != -1L的判断，所以默认的情况下是不会触发int 3 退出的。
可以通过调用_CrtSetBreakAlloc设置_crtBreakAlloc的值，当我们设置了新的_crtBreakAlloc，而且_crtBreakAlloc等于_lRequestCurr时就会触发int 3。
弄清楚了问题的所在，我们就可以着手解决问题了。VC6的dbgheap.c中有两个地方判断了lRequest 是否与_crtBreakAlloc相等，相等后执行指令int 3。我们不用复杂的处理，把int 3替换为nop（0x90）指令即可。首先得到“if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)” 对应的二进制指令，用UE打开msvcrtd.dll，使用16进制编辑模式，查找得到的二进制指令，发现确实只有二处，把紧接着它们的0xCC替换为0x90，问题解决。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/someonea/archive/2008/03/29/2229183.aspx
================================================
问题还不算完，我可以用release版运算，但是总去搞release版也麻烦啊
不知道哪位大侠能告诉我
首先得到“if (_crtBreakAlloc != -1L && lRequest == _crtBreakAlloc)” 对应的二进制指令
这个指令是啥么？
调程序的时候还发现介绍检测内存泄露的一篇好的博客：
关于MFC下检查和消除内存泄露的技巧
摘要
本文分析了Windows环境使用MFC调试内存泄露的技术，介绍了在Windows环境下用VC++查找，定位和消除内存泄露的方法技巧。
关键词：VC++；CRT 调试堆函数；试探法。
编译环境
VC++6.0
技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
注意 #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 <stdlib.h>
#include <crtdbg.h>
只需要按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.
这种情况我采用一种"试探法"。由于内存分配的块号不是固定不变的，而是每次运行都是变化的，所以跟踪起来很麻烦。但是我发现虽然内存分配的块号是变化的，但是变化的块号却总是那几个，也就是说多运行几次，内存分配的块号很可能会重复。因此这就是"试探法"的基础。
先在调试状态下运行几次程序，观察内存分配的块号是哪几个值；
选择出现次数最多的块号来设断点，在代码中设置内存分配断点：
添加如下一行（对于第 18 个内存分配）：
_crtBreakAlloc = 18;
或者，可以使用具有同样效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(18);
在调试状态下运行序，在断点停下时，打开"调用堆栈"窗口，找到对应的源代码处；
退出程序，观察"输出窗口"的内存泄露报告，看实际内存分配的块号是不是和预设值相同，如果相同，就找到了；如果不同，就重复步骤3，直到相同。
最后就是根据具体情况，在适当的位置释放所分配的内存。
本文分析了Windows环境使用MFC调试内存泄露的技术，介绍了在Windows环境下用VC++查找，定位和消除内存泄露的方法技巧。
关键词：VC++；CRT 调试堆函数；试探法。
编译环境
VC++6.0
技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
注意 #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 <stdlib.h>
#include <crtdbg.h>
只需要按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.
这种情况我采用一种"试探法"。由于内存分配的块号不是固定不变的，而是每次运行都是变化的，所以跟踪起来很麻烦。但是我发现虽然内存分配的块号是变化的，但是变化的块号却总是那几个，也就是说多运行几次，内存分配的块号很可能会重复。因此这就是"试探法"的基础。
先在调试状态下运行几次程序，观察内存分配的块号是哪几个值；
选择出现次数最多的块号来设断点，在代码中设置内存分配断点：
添加如下一行（对于第 18 个内存分配）：
_crtBreakAlloc = 18;
或者，可以使用具有同样效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(18);
在调试状态下运行序，在断点停下时，打开"调用堆栈"窗口，找到对应的源代码处；
退出程序，观察"输出窗口"的内存泄露报告，看实际内存分配的块号是不是和预设值相同，如果相同，就找到了；如果不同，就重复步骤3，直到相同。
最后就是根据具体情况，在适当的位置释放所分配的内存。
https://wap.sciencenet.cn/blog-5422-435726.html
上一篇：链表删除过程
下一篇：会议信息--Call for papers
