C++堆被破坏 运行时库

每个进程都有一个默认堆，在进程初始化的时候会创建这个默认堆，可以通过GetProcessHeap()获取默认堆的句柄。使用CRT时，也会有一个CRT堆，VS项目属性 ~ C/C++ ~ 代码生成 ~ 运行库，如果选择多线程DLL，则CRT堆初始化在DLL中，如果选择多线程，则会在进入_tmain函数之前。

要在同一个DLL中对变量进行内存分配和释放的根本原因在于：每个DLL都要保存一份全局变量和静态变量的拷贝；CRT库中将堆的句柄保存为一个全局变量，而堆中内存的分配和释放都要使用这个句柄。如果可执行程序和DLL都使用动态链接的CRT库(/MD,/MDd)，那么CRT库只初始化一次（在其DLL中），每次内存分配和释放也只在CRT的DLL库中进行，这样使用唯一一个堆的句柄，就不会导致错误。
如果有一个DLL(称为D1)使用静态链接的CRT库(/MT,/MTd)，可执行程序也使用静态链接的，那么D1中有一个堆的句柄，可执行程序中也有一个堆的句柄，两者进行内存分配和释放时使用各自的堆的句柄。那么就必须保证使用D1分配的内存，必须由D1释放，否则就会出错。

问题重述

出现异常：Unhandled exception at 0x777F5624 (ntdll.dll) in xxx.exe: 0xC0000374: 堆已损坏
堆被破坏的问题通常是因为内存写越界造成的。因为你分配的两段内存可能恰好连续，前一段内存在写的时候越界，写到第二段的开头，将一些堆数据破坏了。因此报堆损坏的错。也可能是内存不足造成的。

最好不要跨模块new和delete，否则将会出现严重的错误(堆被破坏)。例如在DLL中使用new分配一块内存，之后在EXE中使用delete释放这块内存，有可能堆会被破坏，原因是，如果EXE和DLL都是用静态库的方式链接运行时库，此时EXE和DLL各自将有一个CRT堆，在一个堆上分配内存，之后在另一个堆上释放内存是肯定会发生错误的。如果EXE和DLL都是用动态库的方式链接运行时库，他们使用的是同一个CRT堆，则不会发错误。
一个模块一个堆，一个线程一个栈。dll里malloc的内存，在exe里free会出错。

问题解决

CRT（C运行时期库）不是使用进程缺省的堆来实现malloc（new中调用malloc）的，而是使用一个全局句柄 HANDLE _crtheap 来分配内存的。这个_crtheap是在XXXCRTStartUp（CRT提供的进口点函数）中创建的。 而在dll中的new使用dll中的_crtheap句柄分配堆，在exe中的delete使用exe中的_crtheap释放堆，当然失败！
修复方法：EXE和所有的DLL都必须动态链接/MD到同一份CRT。
1。在DLL中输出一个函数给EXE调用，专门用来释放由DLL分配的内存；
2。用 GlobalAlloc()代替new，用GlobalFree()代替delete；
3。使用单一的堆，分配内存使用 HeapAlloc(GetProcessHeap(),0,size)，释放内存使用HeapFree(GetProcessHeap(),0,p)；
4。把dll和exe的Settings的C/C++选项卡的Code   Generation的Use   Run-time   liberary改成Debug  Multithreaded   DLL，在Release版本中改成Multithreaded   DLL；这样使用一个CRT了——MSVCRT.DLL。
5.无论这些第三方库是静态库还是动态库，或者同时有静态库和动态库(可以同时使用)，必须保证在生成这些库时，使用的C Runtime库是同一个版本（/MT, /MTd, /MD,或者/MDd）【如果是VC的话，在项目属性->配置属性->C/C++->Code Generate->Runtime Library中设置】。 否则，在编译可执行文件时，会出现重复定义的问题，这是因为C Runtime库的不同版本之间的冲突造成的。所以，如果你要提供一个第三方库给别人使用，最好提供使用了不同C Runtime库的多个版本（/MT,/MTd,/MD,或者/MDd）,以供选择。

运行时库的选择

转自：转https://blog.csdn.net/maverick1990/article/details/46649493

运行时库 可以采用的方式有：多线程(/MT)、多线程调试(/MTd)、多线程DLL(/MD)、多线程调试DLL(/MDd)、单线程(/ML)、单线程调试(/MLd)。其中以小写“d”结尾的选项表示的DEBUG版本的，没有“d”的为RELEASE版本。大型项目中必须要求所有组件和第三方库的运行时库是统一的，否则将会出现LNK2005井喷。

Reusable Library	Switch	Library	Macro(s) Defined
Single Threaded	/ML	LIBC	(none)
Static MultiThread	/MT	LIBCMT	_MT
Dynamic Link (DLL)	/MD	MSVCRT	_MT and _DLL
Debug Single Threaded	/MLd	LIBCD	_DEBUG
Debug Static MultiThread	/MTd	LIBCMTD	_DEBUG and _MT
Debug Dynamic Link (DLL)	/MDd	MSVCRTD	_DEBUG, _MT, and _DLL

单线程运行时库选项/ML和/MLd在VS2003以后就被废了。

/MT和/MTd表示采用多线程CRT库的静态lib版本。该选项会在编译时将运行时库以静态lib的形式完全嵌入。该选项生成的可执行文件运行时不需要运行时库dll的参加，会获得轻微的性能提升，但最终生成的二进制代码因链入庞大的运行时库实现而变得非常臃肿。当某项目以静态链接库的形式嵌入到多个项目，则可能造成运行时库的内存管理有多份，最终将导致致命的“Invalid Address specified to RtlValidateHeap”问题。另外托管C++和CLI中不再支持/MT和/MTd选项。

/MD和/MDd表示采用多线程CRT库的动态dll版本，会使应用程序使用运行时库特定版本的多线程DLL。链接时将按照传统VC链接dll的方式将运行时库MSVCRxx.DLL的导入库MSVCRT.lib链接，在运行时要求安装了相应版本的VC运行时库可再发行组件包（当然把这些运行时库dll放在应用程序目录下也是可以的）。 因/MD和/MDd方式不会将运行时库链接到可执行文件内部，可有效减少可执行文件尺寸。当多项目以MD方式运作时，其内部会采用同一个堆，内存管理将被简化，跨模块内存管理问题也能得到缓解。

结论：/MD和/MDd将是潮流所趋，/ML和/MLd方式请及时放弃，/MT和/MTd在非必要时最好也不要采用了。

选项	说明
/MD	使应用程序使用运行时库的多线程并特定于 DLL 的版本。定义 _MT 和 _DLL，并使编译器将库名  MSVCRT.lib 放入 .obj 文件中。 用此选项编译的应用程序静态链接到 MSVCRT.lib。该库提供允许链接器解析外部引用的代码层。实际工作 代码包含在 MSVCR80.DLL 中，该库必须在运行时对于与 MSVCRT.lib 链接的应用程序可用。 当在定义了 _STATIC_CPPLIB (/D_STATIC_CPPLIB) 的情况下使用/MD 时，它将导致应用程序与静态多 线程标准 C++ 库 (libcpmt.lib) 而非动态版本 (msvcprt.lib) 链接，同时仍通过 msvcrt.lib 动态链接 到主 CRT。
/MDd	定义 _DEBUG、_MT 和 _DLL，并使应用程序使用运行时库的调试多线程并特定于 DLL 的版本。它还使编 译器将库名 MSVCRTD.lib 放入 .obj 文件中。
/MT	使应用程序使用运行时库的多线程静态版本。定义 _MT 并使编译器将库名 LIBCMT.lib 放入 .obj 文件中 ，以便链接器使用 LIBCMT.lib 解析外部符号。
/MTd	定义 _DEBUG 和 _MT。此选项还使编译器将库名 LIBCMTD.lib 放入 .obj 文件中，以便链接器使用  LIBCMTD.lib 解析外部符号。
/LD	创建 DLL。 将 /DLL 选项传递到链接器。链接器查找 DllMain 函数，但并不需要该函数。如果没有编写 DllMain  函数，链接器将插入返回 TRUE 的DllMain 函数。 链接 DLL 启动代码。 如果命令行上未指定导出 (.exp) 文件，则创建导入库 (.lib)；将导入库链接到调用您的 DLL 的应用程 序。 将 /Fe（命名 EXE 文件）解释为命名 DLL 而不是 .exe 文件；默认程序名成为basename.dll 而不是 basename.exe。 除非显式指定 /MD，否则将暗指 /MT。
/LDd	创建调试 DLL。定义 _MT 和 _DEBUG。