相关软件 /中文/ /英文/ /英文/ /中文/ /英文/ /英文/ /中文/ /英文/ /英文/ /英文/顶好评:50%踩坏评:50请简要描述您遇到的错误，我们将尽快予以修正。轮坛转帖HTML方式轮坛转帖UBB方式
25.0M/英文/7.2
33.8M/中文/5.4
23.8M/中文/4.2
303M/中文/1.5
651.2M/中文/3.1
41.1M/英文/5.5
11.2M/中文/7.0
Dr. Memory 是一个开源免费的工具，它能够及时发现内存相关的编程错误，比如未初始化访问、内存非法访问以及内存泄露等。它不仅能够在 Linux 下面工作，也能在微软的 Windows 操作系统上工作。不过，本文撰写时，DrMemory 仅能支持 32 位程序，这是它的一个巨大缺陷，但相信随着开发的进行，DrMemory 会推出支持 64 位程序的版本。Dr Memory特点：Dr Memory 与 Valgrind 类似，可以直接检查已经编译好的可执行文件。用户不用改写被检查程序的源代码，也无须重新链接第三方库文件，使用起来非常方便。易用性和性能是 DrMemory 的主要优点，此外 DrMemory 可以用于调试 Windows 程序，因此它被广泛认为是 Windows 上的 Valgrind 替代工具。在 Linux 平台中，DrMemory 也往往可以作为 Valgrind 之外的另一个选择。DrMemory 对内存泄露的监测采用了比较独特的算法，大量减少了”false positive”，即虚假错误。如果您使用 Valgrind 等工具后仍无法找到程序中的内存错误，不妨试试 DrMemory 吧。Dr. Memory 建立在 DynamoRIO 这个动态二进制插桩平台上。动态监测程序的运行，并对内存访问相关的执行代码进行动态修改，记录其行为，并采用先进的算法进行错误检查。C++程序员最大的敌人就是内存处理错误，比如内存泄露、内存溢出等。这些错误不易发现，调试困难。本文介绍一个新的内存调试工具 DrMemory，为您的工具箱中添加一个新的内存检查利器吧。Dr Memory内存检测实例：Dr. Memory 建立在 DynamoRIO 这个动态二进制插桩平台上。动态监测程序的运行，并对内存访问相关的执行代码进行动态修改，记录其行为，并采用先进的算法进行错误检查。根据 DrMemory 开发人员发表在 CGO 2011上的论文 Practical Memory Checking with Dr. Memory，DrMemory 对程序的正常执行影响较小，这在同类工具中是比较领先的。其 performance 和 Valgrind 的比较如图 1 所示(图片源自 DrMemory 主页)：图 1. 和 Valgrind 的性能比较Valgrind 对程序的正常运行影响较大，一般来说如果进行全面内存检测，会使程序的运行速度有 50 到 300 倍的减慢。而 DrMemory 在这个方面则有一定的优势。易用性和性能是 DrMemory 的主要优点，此外 DrMemory 可以用于调试 Windows 程序，因此它被广泛认为是 Windows 上的 Valgrind 替代工具。在 Linux 平台中，DrMemory 也往往可以作为 Valgrind 之外的另一个选择。DrMemory 对内存泄露的监测采用了比较独特的算法，大量减少了”false positive”，即虚假错误。如果您使用 Valgrind 等工具后仍无法找到程序中的内存错误，不妨试试 DrMemory 吧。Windows 上 DrMemory 提供了可执行安装包，只需点击下一步，即可安装完毕。DrMemory，第一印象 DrMemory 的使用很简单，可以说它是傻瓜式。正常运行一个程序时，我们在 shell 中敲入命令然后回车。为了用 DrMemory 检查，只需要在Hello DrMemory，第一印象DrMemory 的使用很简单，可以说它是傻瓜式。正常运行一个程序时，我们在 shell 中敲入命令然后回车。为了用 DrMemory 检查，只需要在正常命令之前加入 drmemory.pl，比如程序检查程序 t，那么就这样:drmemory.pl&&./t在计算机领域，Helloworld 总是第一个程序。让我们写一个 HelloDrMemory，来和 DrMemory 简单接触一下吧。清单 1，Hello DrMem 例子程序1:&&&int&main()
3:&&&&&char&*
4:&&&&&int&i;
5:&&&&&for(i=0;i&100;i++)
7:&&&&&&&ptr=(char*)malloc(i);
8:&&&&&&&if(i%2)&free(ptr);
10:&&&&return&0;
11:&&}很明显，有 50 个内存泄露，都在同一行代码中（Line 8）。让我们用 Dr Memory 来检查它。屏幕上会有如上所示的错误汇总，注意看 ERRORS FOUND 下面的第 5 行：”50 total leaks”。不错吧。根据提示，更多的细节被写入一个 result 文本文件。打开并查看该文件，就可以知道程序在哪里出现了内存错误了。真是太方便了。不过 result 文件是否容易阅读呢？下面我们来详细解释如何阅读 DrMemory 产生的 result 文件。DrMemory 报告解读细节内存非法访问DrMemory 认为任何对未分配内存区域的读写都是非法的。在 Linux 中，应用程序可以用以下几个方式分配内存：调用 mmap (或者 mremap)调用 malloc 在堆上分配内存使用 alloca 在栈上分配内存非法访问就是对以上三种方法分配的内存区域之外进行的访问。常见的问题包括 buffer overflow、数组越界、读写已经 free 的内存、堆栈溢出等等。让我们测试下面这个问题程序。Buffer overflow例子程序的第 5 到 6 行存在 buffer overflow。在内存中，buffer 的分布如下图所示：图 2. Buffer 分布访问 x+8 将产生一个非法内存访问。对此，Dr Memory 将给出如下的错误信息：首先用大写的单词 UNADDRESSABLE ACCESS 表明这是一个非法访问错误。接着，“reading 0xx byte(s)”表示这是一个非法读，读取的范围为 0x 到 0x，一共读了 1 个 byte。接下来的三行是调用堆栈信息，可以方便地看到错误发生在哪个源文件的哪一行（程序 t 需要在用 gcc 编译的时候给定-g 选项）。此外 DrMemory 还给出了一些辅助的错误信息。比如：错误发生的时间：Note: elapsed time = 0:00:00.133 in thread 13971。这表明错误是程序开始的第 0.133 秒后发生的，有些情况下，人们可以根据这个时间进行辅助判断。错误细节：Note: refers to 1 byte(s) beyond last valid byte in prior malloc。这里给出了错误的详细信息，如前所述，造成非法访问的可能很多，在本例中是 buffer overflow，因此这里的详细信息可以帮助我们了解非法访问的具体原因。Note: prev lower malloc: 0xx。这里给出了 overflow 之前的合法内存地址，有些情况下对于查错 有一定的帮助。Note: instruction: movzx (%eax) -& %eax。这里给出的是造成错误的具体指令。可以看到 DrMemory 只报告了一个未初始化读错误，在第 12 行。很多其他工具对于 memcpy(&b,&a, sizeof(T))也会报错。GCC 将自动对齐数据结构(未使用 pack 修饰符的情况下)。因此 struct T 在内存中的实际分布如下：图 3. 内存拷贝细节在 memcpy 时，有 3 个未初始化 byte 也被访问了，但这类错误如果也报告的话，对正常程序 DrMemory 会产生很多错误信息。这些其实不是错误，所以被称为 False Positive。类似医学名词“假阳性”。内存调试工具的一个主要目标就是减少 False Positive，否则产生的报告有用性将极大降低。其它很多工具，遇到上述拷贝会报告 false positive，浪费读报告的人们的时间。因此这是 Dr Memory 的一个重要优点。内存泄露内存泄露是常见的内存错误，我们可能都曾经遇到过。不过 Dr.Memory 对内存泄露的定义比较独特，在程序退出之前，Dr.Memory 把所有依然被分配的内存分为三类：Still-reachable allocation很多程序分配了内存之后，在其整个生命周期内都不释放。虽然这是一种泄露，但实际上多数情况下这是无害的，甚至是特意这样设计的。因此 Dr.Memory 并不认为这是一种内存泄露，而称之为”Still-reachable allocation”。Leak有一些内存无法再被释放，因为指向该内存的指针丢失了。比如下面这个代码：清单 5.内存 Leak 例子代码DrMemory 称这类错误为内存泄露。因为这些内存已经没有办法被释放了。Possible Leak如前所述指向内存的指针被修改会被认为是一个 Leak，但并非所有的指针修改都是一个 Leak。DrMemory 利用一些经验规则(Heuristic)将以下几种指针修改列为 Possible Leak。第一种情况：C++程序利用 new[]分配了一个数组，该数组的每个元素都是 拥有自己的析构函数的复杂数据结构。这种情况下，New 操作符为每个元素加上一个 header 用来保存数组的个数，以便 delete[]操作符知道需要调用多少个析构函数。但 new[]返回 caller 的是 header 之后的地址，这样就变成了一个 mid-allocation 指针。这可能被 Dr memory 认为是一个内存泄露。但可以使用-no_midchunk_new_ok 选项让 DrMemory 将这类错误报告为”possible leak”而非”leak”。参考下图，理解这种情况。图 4.mid-chunk new从堆分配器的角度来看，buffer 的起点在 A 处，但 new 返回 B，给 Object 变量赋值。从某种角度上看，指针 A 丢失了，是一个 leak，但实际上，当调用 delete []操作符时，C++运行时库会自动将 Object 指针减 4，从而指向 A 点，再进行释放。某些编译器不使用这种做法，则没有这个问题。第二种情况，某些 C++编译器在处理多继承时，会出现 mid-chunk 指针。很抱歉，具体细节本人也不甚了解。Dr Memory 的原文如下：it includes instances of a pointer to a class with multiple inheritance that is cast to one of the parents: it can end up pointing to the subobject representation in the middle of the allocation. 您可以用-no_midchunk_inheritance_ok 选项将这类“错误”报告为”possible leak” 。还有一种可能：std::string 类把一个 char[]数组放置在分配空间中，并返回一个指针直接指向它，造成了一个 mid-allocation 指针。您可以用-no_midchunk_string_ok 选项让这类错误显示为”possible leak”。一些有用的选项：现实世界中真正的程序有很多不同于本文中所罗列的那些例子程序，现实程序更复杂，查找错误并不像例子所示的那么容易。DrMemory 设计了一些辅助选项，灵活使用它们才能在真正的工作中得到有用的信息。监控子程序缺省情况下 DrMemory 将监控当前进程产生的子进程的内存错误。如果您想禁止检查子进程，可以使用-no_follow_children 选项。合并检查结果用-aggregate 选项可以合并 DrMemory 的检查结果，比如下面的命令把 logs 目录下面多个 DrMemory 报告合并为一个总的报告。这个功能在某些情况下比较有用。比如对同一个程序用多个不同的测试用例测出不同的内存错误，可以把多个报告合并起来，以便程序员一次阅读。检查不退出程序一些程序永远或者长时间都不退出，对于某些内存错误，比如未初始化读写，或者非法读写，DrMemory 一旦发现就立即写入 result 文件。但 DrMemory 只有在进程退出时才检查内存泄露。因此对于长期运行的程序，如果我们想在其运行期间得到内存泄露的报告，就需要使用 DrMemory 的 nudge 命令。比如您的进程 pid 为 1000，正在被 DrMemory 检测。那么你可以在 Shell 中运行下面这条命令，强制 DrMemory 进行内存泄露检查，并把结果更新到 result 文件中。现在打开 result 文件，如果程序有内存泄露，您将在该文件中找到错误信息。Suppressing Errors内存错误检查工具的一个重要能力就是能够 suppress errors，即隐藏指定”错误”的能力。因为人们使用内存错误检测工具最希望的是它能给出“真正的”错误，而不是给出大量的不是错误的错误。工具本身可以根据一些经验算法隐藏一些“众所周知”的假错误。但更多的情况下，需要使用者告诉工具如何区分出假错误。每次运行 DrMemory 时，它会产生一个 suppress 文件，和 result 文件放在一起。该文件的格式如下：图 5. suppress 文件格式suppress 文件有多个”One Error”小节组成，每个”One Error”表示一个可以被 suppress 的错误。用调用堆栈来表示，有两种格式来表示堆栈:DrMemory 支持通配符，比如 t!*表示不报告所有模块 t 中的错误。在 Linux 下面，模块 t，就是由 t.c 生成的 t.o 所包含的代码，换句话说就是不检查 t.c 中的错误。一些有用的选项：现实世界中真正的程序有很多不同于本文中所罗列的那些例子程序，现实程序更复杂，查找错误并不像例子所示的那么容易。DrMemory 设计了一些辅助选项，灵活使用它们才能在真正的工作中得到有用的信息。监控子程序缺省情况下 DrMemory 将监控当前进程产生的子进程的内存错误。如果您想禁止检查子进程，可以使用-no_follow_children 选项。合并检查结果用-aggregate 选项可以合并 DrMemory 的检查结果，比如下面的命令把 logs 目录下面多个 DrMemory 报告合并为一个总的报告。这个功能在某些情况下比较有用。比如对同一个程序用多个不同的测试用例测出不同的内存错误，可以把多个报告合并起来，以便程序员一次阅读。检查不退出程序一些程序永远或者长时间都不退出，对于某些内存错误，比如未初始化读写，或者非法读写，DrMemory 一旦发现就立即写入 result 文件。但 DrMemory 只有在进程退出时才检查内存泄露。因此对于长期运行的程序，如果我们想在其运行期间得到内存泄露的报告，就需要使用 DrMemory 的 nudge 命令。比如您的进程 pid 为 1000，正在被 DrMemory 检测。那么你可以在 Shell 中运行下面这条命令，强制 DrMemory 进行内存泄露检查，并把结果更新到 result 文件中。现在打开 result 文件，如果程序有内存泄露，您将在该文件中找到错误信息。Suppressing Errors内存错误检查工具的一个重要能力就是能够 suppress errors，即隐藏指定”错误”的能力。因为人们使用内存错误检测工具最希望的是它能给出“真正的”错误，而不是给出大量的不是错误的错误。工具本身可以根据一些经验算法隐藏一些“众所周知”的假错误。但更多的情况下，需要使用者告诉工具如何区分出假错误。每次运行 DrMemory 时，它会产生一个 suppress 文件，和 result 文件放在一起。该文件的格式如下：图 5. suppress 文件格式suppress 文件有多个”One Error”小节组成，每个”One Error”表示一个可以被 suppress 的错误。用调用堆栈来表示，有两种格式来表示堆栈:DrMemory 支持通配符，比如 t!*表示不报告所有模块 t 中的错误。在 Linux 下面，模块 t，就是由 t.c 生成的 t.o 所包含的代码，换句话说就是不检查 t.c 中的错误。
C++内存检测工具(Dr Memory) 1.7.0 官方最新版
下载帮助西西破解版软件均来自互联网, 如有侵犯您的版权, 请与我们联系。C++ 中 ZeroMemory、memset 危险需慎用_Linux编程_Linux公社-Linux系统门户网站
你好，游客
C++ 中 ZeroMemory、memset 危险需慎用
来源：Linux社区&
作者：tjunxin
使用C/C++编程时，常使用ZeroMemory、memset或 &={0}&来对结构体对象进行初始化或清零。然而这三种方式都有各自的特点，使用时需谨慎，否则容易出现严重错误，本人今日解决一个导致宕机的bug，查了几小时，才发现是由同事乱用ZeroMemory所致。于是搜集资料，撰此文以共勉。
void *memset(void *s,int ch,size_t n); 是由C Run-time Library提供的提供的函数，作用是在一段内存块中填充某个给定的值，它是对较大的结构体或数组进行清零操作的一种最快方法。由于是语言层面提供，所以可跨平台使用。
char str[] = "almost every programmer should know memset!";memset (str,'-',6);puts (str);
------ every programmer should know memset!
ZeroMemory
ZeroMemory是美国微软公司的软件开发包SDK中的一个宏。 其作用是用0来填充一块内存区域。定义式如下
#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))#define ZeroMemory RtlZeroMemory
由此可见：
1.ZeroMemory实际是用memset实现的。
2. ZeroMemory只能用于windows平台。
ZeroMemory和memset且于清零时，会将结构中所有字节置0，如果结构体中有虚函数或结构体成员中有虚函数，则会将虚函数指针置0，如果后续程序调用虚函数，空指针很可能导致程序崩溃！
因此，有虚函数或成员中有虚函数的结构体初始化，一定要用构造函数来完成。
另外，如果一个类的结构中包含STL模板（Vector、List、Map等等），那么使用ZeroMemory对这个类的对象中进行清零操作也会引起一系列的崩溃问题（指针指向内存错误、迭代器越界访问等）。所以，再次强烈建议：类(class)只使用构造函数进行初始化，不要调用ZeroMemory进行清零操作。
#include "stdafx.h"#include &Windows.h&
class Car{public:&virtual void Run(){}private:&int m_};struct&SRace& {&C&};
int _tmain(int argc, _TCHAR* argv[]){&SR&ZeroMemory(&race,sizeof(race));&&// 没通过虚表指针调用，没事&race.car.Run();&&Car *pCar = &race.
&// __vfptr = 0x，崩溃&pCar-&Run();
&return 0;}
={0}操作是结构体和数组的一种初始化方式，它是将结构体中基本类型变量赋默认值，当结构体中有非基本类型（例如类对象）时，会编译错误，这也是一种保护。
相关资讯 & & &
& (12月07日)
& (11月10日)
& (12月07日)
& (08月29日)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款工具类服务
编辑部专用服务
作者专用服务
基于有界模型检测的C/C＋＋程序内存泄露检测
C ／C ＋＋语言中的动态内存管理机制自由且灵活，但动态内存的使用容易引入内存泄露，导致系统性能降低甚至系统崩溃。为了更加有效地检测内存泄露，提出了一个基于有界模型检测技术的 C ／C ＋＋程序内存泄露检测方案 MLD-CBMC。该方案以 C ／C ＋＋程序文件为输入，利用有界模型检测技术对程序进行展开处理，加入内存泄露性质，并利用可满足性模理论（SMT）对程序约束和性质组成的验证条件编码，使用 SMT 求解器对验证条件求解，将检测内存泄露问题转换为求解可满足性问题，实现 C ／C ＋＋程序内存泄露的检测。通过实验验证了方案的有效性，并与其他有界模型检测工具进行对比实验，实验证明方案对内存泄露的检测能力更强。
Abstract：
The dynamic memory management mechanism in C /C ++programming language is free and flexible,but when used by developer it is easy to introduce memory leaks which lead to performance degradation and even failure of system.In order to detect memory leak more effectively,this paper proposed a memory leak detection method based on bounded model checking for C program called MLD-CBMC.It took C /C ++program files as input,unwound the program and inserted memory leak proper-ties,encoded the program constraints and properties into verification conditions using satisfiability modulo theory,then passed the verification conditions to a SMT solver.Thus it converted detecting memory leaks to solving satisfiability problems.By ex-periment and cooperation with other bounded model checking tools,MLD-CBMC shows its feasibility and effectiveness.
Yang Qiuhui
Dai Shengxin
Xu Baoping
Gao Wanling
作者单位：
四川大学 计算机学院,成都,610065
年，卷(期)：
Keywords：
在线出版日期：
基金项目：
四川省应用基础研究项目
本文读者也读过
相关检索词
万方数据知识服务平台--国家科技支撑计划资助项目（编号：2006BAH03B01）(C)北京万方数据股份有限公司
万方数据电子出版社#define&_CRTDBG_MAP_ALLOC#include&&stdlib.h&#include&&crtdbg.h&
NB:对于不使用 malloc , calloc ，只使用 new 对内存进行使用的程序 &stdlib.h& 可不包含。 [] 中说必须保持如上代码的书写顺序，不知是什么原因。（？？？）如果程序的退出点只有一个，可以在主程序的入口使用 _CrtSetDbgFlag ，使程序在调试状态运行结束后，在输出窗口输出内存泄漏点的信息，或者在主程序的出口使用 _CrtDumpMemoryLeaks ，使程序在调试状态运行结束后，在输出窗口输出内存泄漏点的信息。如果程序有多个退出点，使用 _CrtDumpMemoryLeaks 的话，&需要在每个退出点对 _CrtDumpMemoryLeaks 进行调用，而使用 _CrtSetDbgFlag 只需在程序的入口点进行一次调用。相比较而言，如果程序有多个退出点，使用 _CrtSetDbgFlag 会比较方便。在输出窗口输出的 Memory Leak 的信息格式如下：
Detected&memory&leaks!Dumping&objects&-&c:\users\\desktop\workshop\temp.cpp(<span style="color: #)&:&{<span style="color: #9}&normal&block&at&<span style="color: #x007C96E8,&<span style="color: #&bytes&long.&Data:&&&&&&&&&&&&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&Object&dump&complete.
此信息指明了内存泄漏点所在的源文件及行号：...\temp.cpp(46)，内存的分配号：{139}，内存块的类型：normal block, 内存块的地址：0x007c96e8, 内存泄漏的大小：8 bytes long, 以及此内存块前 8 个字节的内容：Data:&&&&& & 00 00 00 00 00 00 00 00。上面的 Memory Leak 输出的格式是在使用 malloc , calloc 的情况下输出的。如果使用 new 的话，输出的 Memory Leak 的格式如下：
Detected&memory&leaks!Dumping&objects&-&{<span style="color: #9}&normal&block&at&<span style="color: #x,&<span style="color: #&bytes&long.&Data:&&&&&&&&&&&&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&<span style="color: #&Object&dump&complete.
与上一个输出的 Memory Leak 的信息相比，这个输出缺少了内存泄漏点的源文件及行号。在这种情况下怎么办呢？一般有两种方法：1）定义宏 new ，使得对 new 操作符的调用，转换到对新定义的宏的调用，在宏定义中加入源文件名与行号，使行在输出的 Memory Leak 的信息中包含有源文件名与行号；2）使用 &crtdbg.h& 中的 _crtBreakAlloc 根据内存分配号下断点，使得程序运行到内存泄漏点时暂停。定义宏 new 的代码如下：
#ifdef&_DEBUG&#ifndef&DBG_NEW&&#define&DBG_NEW&new&(_NORMAL_BLOCK&,&__FILE__&,&__LINE__)&&#define&new&DBG_NEW&#endif#endif&//&_DEBUG
把些代码放到程序开始的位置，当在 Debug 模式下运行结束后，输出窗口便会输出包含源文件名与行号的 Memory Leak 的信息了。如果这种方法不可行，那么只能使用第 2) 中方法了, 即使用 _crtBreakAlloc 。_crtBreakAlloc 实际上是一个 long int 类型的变量，如果在代码中使用的话，需要在程序的入口处对 _crtBreakAlloc 赋值为待查找的内存泄漏点的内存分配号，比如：
_crtBreakAlloc&=&<span style="color: #9;
如果在调试的 Watch 窗口中使用的话，需要做一些变化。在 Watch 窗口的 name 列中输入_crtBreakAlloc 然后在 value 列中输入待查找的内存泄漏点的分配号，比如 139。然后在DEBUG 模式下继续运行，调试器便会在对分配号为 139 的内存块进行分配时中断，这里查看代码与堆栈便可定位内存泄漏点的位置了。如果程序中使用的是多线程的 CRT ，在 Watch 窗口中的 name 列中输入的内容要稍作修改，改为 {,,msvcr120d.dll}_crtBreakAlloc。其中的 120 可根据不同的 Visual Studio 的版本所使用的 CRT 的版本作相应的修改。上述步骤完全是按照 [] 中所描述的方法做的，实际上却行不通，不知为何。(??????)要想在 Watch 窗口中使得这种方法有效，还需要修改下 name 列中的名字。当修改为 (long*){,,msvcr120d.dll}__crtBreakAlloc 时(两个下划线)，再在其 value 列中填入待查找的内存的分配号便可以了。[] 在 Watch 窗口中设置这个值的前提是在程序的入口处，或者所认为的可能的内存申请语句之前下断点，使程序停在这里后，再按这种方法设置，设置好后，让程序继续在 DEBUG 模式下运行。上面所说的是根据程序在 DEUBG 模式下调试运行结束时，output 窗口中输出 Memory Leak 的信息来定位内存泄漏点。下面来说另外一种方法，即使用&crtdbg.h& 中的 _CrtMemCheckpoint ,&_CrtMemDifference , _CrtMemDumpStatistics 来定位导致内在泄漏的代码块。这种方法同前面一种方法一样，也需要定义宏 _CRTDBG_MAP_ALLOC，和包含 &crtdbg.h&。找到可能导致内存泄漏的代码段，用两个 _CrtMemCheckpoint 的调用把可能代码段包起来，在后一个 _CrtMemCheckpoint 调用之后，调用 _CrtMemDifference ，再使用 _CrtMemDumpStatistics 输出比较结果到 output 窗口。一步步缩小排查的范围，最终找出导致内存泄漏的元凶。参考链结：[Ref 1]: [Ref 2]: