前段时间，封装一个库，开始用VS2010封装的，写了一个demo，测试完全没有问题，后来同事需要调用我的那个库，需要我编译一个VS2003版的dll库给他，我就重新封装了一个库，写了个demo一测试，运行是没问题，快结束时，总是报_CrtIsValidHeapPointer出错；因为开始在10版本里面没有问题，封装了03版本才出的问题，总是觉得自己是不是库的接口什么地方写的有问题，导致出栈入栈有问题，试了半天，问题依旧不能解决，后来在网上一搜，才发现，原来是选择的运行时库有问题，封装库的时候，03默认选择了Single-threaded Debug (/MLd)，而我在demo中、以及后面的调用中，都用的Multi-threaded Debug DLL (/MDd)；改完之后，终于没有问题了；觉得网友对这块问题的剖析的挺透彻的，分享一下！
在不同的模块分配的内存，释放的时候会出现此问题，而此问题，只在Debug模式会提示，Release模式不会提示。但不提示并不代表没有错误，一定要解决之。解决的方法是：在哪个模块分配的内存，就在哪个模块释放。
这个错误有两种可能：
一.释放的问题
1，内存不能跨模块分配和释放，模块分配的内存必须由该模块自己来释放。应该在DLL中再加一个方法，比如MemRelease，主程序调用这个方法来释放内存。
2，就是绕过new和delete，用GlobalAlloc()和GlobalFree()的方法
二.动态链接库的问题
这个问题有两种情况：
1.链接外部lib出错：当前是Debug模式，但工程属性->Configureation Properties->Linker->Input->Additional Dependencies 中的链接库用的却是Release版本的，这个要仔细检查才行。相同道理，Release的模式下也有错用Debug链接库的问题。
2.ruantime Linbrary 方式选择错误：工程属性->Configureation Properties->C/C++->Code Generation->Runtime Library中的选项有可能与当前的编译方式不符。比如当前是Release模式却选择了Multi-threaded Debug DLL (/MDd)，相反当前是Debug模式却选择的是Multi-threaded DLL (/MD)。
今天遇到了这个assert，发现是dll中的一个局部vector释放的时候报的，这个vector是在dll中定义的，然后实在exe中分配的空间（通过引用传参数，然后调用push_back方法)，这样，vector释放的时候它会发现dll正在释放一个不是由dll分配的内存，所以就会出此断言，一个临时的解决方案是，在dll中分配，可以通过vector的reserve方法来实现，当然，更好的解决方法是上层避免这种用法
还有在使用mfc时也遇到过这个问题，
mfc主程序中引用了一个dll，在dll中动态分配了一个对象，然后在主程序中释放，就会出现问题，是由于程序是静态依赖mfc运行时库的，这样在释放的时候，只查找主程序所在的堆空间，应用程序就认为释放了一个不再堆列表中的地址，而改为动态依赖mfc，程序才会查找依赖的dll中的堆列表，所以就没有问题了
从CrtIsValidHeapPointer的实现代码处我们可以得知，这个函数不仅检查了空指针的情况，更重要的是检查了指针地址的有效性。
我遇到的问题：
释放内存时，弹出assert，报错的函数就是上面提到的这个：CrtIsValidHeapPointer。
可是为什么会报错呢？CrtIsValidHeapPointer的注释上说明了情况：如果要释放的内存地址不是在当前控制的堆的地址范围内，也会报这样的错误。
问题分析：
1、我的实现是在exe中调用dll的一个方法，这个方法里面里面会分配若干内存，并将数据拷贝到新分配的内存中，传递出去；之后我会在exe中对这部分内存进行释放。
2、同一个进程，难道还有两个堆？如果你的工程Runtime Library选择的是MT（使应用程序使用运行时库的多线程静态版本）类型，那么，是的，确实是这样，dll和exe是分别的两个堆。
3、也就是说，dll中分配的内存只能在dll中进行释放，否则CrtIsValidHeapPointer函数就会报错
起初觉得怎么这样呢？但考虑到不用dll的实现者是不一样的，那么他本身的选择的运行时库的链接方式也可能不一样，非要把他们都放在一个堆上操作反而会使问题变得复杂。CRT的这种处理确实更为合理。
解决方法：
既然谁分配谁释放，而我要分配的内存大小只有dll自己知道，我只好将分配内存的事情放在了dll中，然后dll再提供一个释放内存的方法。类似：
1、allocAndGetData(CData** ppData);
2、freeData(*pData);
文章二
_CrtIsValidHeapPointer()在Debug模式下测试一个地址在本地的堆内存中，如果采用共享的方式链接C运行时库那么不会出现什么问题，但是如果采用静态的方式链接C运行时库，那么调用该DLL中的函数时就可能出现问题。提示一个错误.
例如：有两个DLL文件 a.dll ,b.dll 且a.dll采用静态的方式链接C运行时库。
如果 a.dll 中导出一个函数 CString aFun()，按值返回一个字符串。
如果 b.dll 中调用该函数如 CString str=aFun();
b.dll调试运行时将出现错误，提示_CrtIsValidHeapPointer()出错.
在MSDN中查找该函数说明知，当一个DLL采用静态的方式链接到C运行时库时，会创建一个相对于该DLL的堆(Heap)，而如果采用共享的方式链接到C运行时库的时候则使用的是应用程序的堆内存。而_CrtIsValidHeapPointer()在 DEBug模式下将确保传入的地址在本地的堆内存中，这样问题就明显了：
a.dll采用静态链接C运行时库，所以会创建一个相对于该DLL的堆内存，这样a.dll中分配的临时变量均在该堆中分配。
再看a.dll中的函数aFun()以值的方式返回了一个字符串，执行到return语句时会创建一个临时的变量作为返回，但此临时变量内存却在a.dll的堆内存中，当在b.dll中调用时，语句CString str=aFun();完成时该临时变量的CString析构函数被调用，会释放内存空间，但此时_CrtIsValidHeapPointer()检测到该内存地址不在本地的堆内存中，产生一个错误。但忽略该错误程序有时对正确运行。
解决的办法是将a.ll采用共享的方式链接到C运行时库。
这个错误花了很长时间才找出来，哈哈。。。。
文章三
这是因为dll拥有一个独立于应用程序（调用它的exe）的本地堆，调用过后dll占用的空间即被释放，先前new的内存地址即无效，那么解决此问题时要将dll文件中动态申请内存的时候使用HeapCreate函数而不能使用new操作符，具体说明详见MSDN，以下网址可供参考：
问题就出在红色的地方，自定义了一个类
将上面的语句改为
ColHistogram
pMyColHist = new ColHistogram;
就可以了，不过现在也不知道为什么
(MSDN)中的这段话
The _CrtIsValidHeapPointer function is used to ensure that a specific memory address is within the local heap. The “local” heap refers to the heap created and managed by a particular instance of the C run-time library. If a dynamically linked library (DLL) contains a static link to the run-time library, then it has its own instance of the run-time heap, and therefore its own heap, independent of the application’s local heap. When _DEBUG is not defined, calls to _CrtIsValidHeapPointer are removed during preprocessing.
看了这段话稍微觉得有点意思了，我在程序中自己申请了本地堆，也有要生成动态连接库的DIB类，要连接c运行库，那么我的ColHistogram的实例必须动态生成，因为它在c运行库中没有对应的堆。比如我添加Cstring str;程序就不会有问题，但是我只知道CString是系统定义的，和c运行库有什么关系我就不清楚了。如果静态链接C运行库，那么，dll就要拥有一个独立于应用程序（调用它的exe）的本地堆（但是我的程序没有），如果没有定义_DEBUG，那么_CrtIsValidHeapPointer将被预处理器移除。大概就是这个样子，上面所说的很多东西我都不确定，只是现在的一种解释。
还有dbgheap.c文件似乎是在dll里，还没有办法看
这是ms的一个已知bug，原因：
The reason why you get this error is that a winforms application has a managed entry point. The initialization of the native global objects is done by the CRT (C RunTime) startup routine. Since in this case there is no CRT startup routine the MyBoard global object fails to initialize correctly.
IDE is specific the entry of ManagedApp as "main". However, using "main" will bypass a lot of CRT's startup initialization.
解决方法：
右键点击项目--->properties--->link--->advanced
把Entry Point从main改为 "?mainCRTStartupStrArray@@$$FYMHP$01AP$AAVString@System@@@Z"
原理：
That should re-enable the CRT startup code which initializes the internal CRT variables.That symbol is really the mangled name for "int __clrcall mainCRTStartupStrArray(cli::array^)".
malloc/free
malloc/free是C和C++语言的标准库函数, 可以被覆盖, 需要头文件库函数支持,
不在编译器控制范围之内, 不能够执行构造函数和析构函数的任务
malloc标准库函数的作用：分配动态堆内存
free标准库函数的作用：释放动态堆内存
用malloc分配的一块内存, 你要用指针访问并且要通过移动指针来访问内存数据
malloc只认字节数, 不管数据类型, 只能返回一个void*, 程序员要把void*强制类型转换成相应的指针类型,
同时还要用 if (NULL != ...) 来判断申请内存空间是否成功
new/delete是C++的操作符, 是保留字, 可以被重载, 不需要头文件支持,
在编译器控制范围之内, 能够执行构造函数和析构函数的任务
new操作符的作用：分配动态堆内存、初始化对象(调用构造函数)
delete操作符的作用：清理对象(调用析构函数)、释放动态堆内存
用new创建的对象, 你可以用成员函数访问, 不用直接访问它的地址空间。
new可以认为是malloc加构造函数的执行, new出来的指针是直接带类型信息的, 不用进行强制类型转换
对于基本数据类型来说, 由于不像“对象”那样有构造与析构的过程，所以对它们而言,
malloc/free 和 new/delete是等价的
既然new/delete的功能完全覆盖了malloc/free, 为什么C++不把malloc/free淘汰出局呢?
因为C++程序经常要调用C函数, 而C程序只能用malloc/free分配和释放动态堆内存
内存泄漏对于malloc或者new都可以检查出来的, 区别在于new可以指明是那个文件的那一行, 而malloc没有这些信息
如果用free释放“new创建的动态对象”, 那么该对象因无法执行析构函数而可能导致程序出错。
如果用delete释放“malloc申请的动态内存”, 理论上讲程序不会出错, 但是该程序的可读性很差。
所以new/delete必须配对使用, malloc/free也一样。
int* p = (int*)malloc(5 * sizeof(int));
void* __cdecl malloc(size_t nSize)
{
}
void* __cdecl _nh_malloc_dbg(size_t nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine)
{
}
void* __cdecl _heap_alloc_dbg(size_t nSize, int nBlockUse, const char * szFileName, int nLine)
{
}
void* __cdecl _heap_alloc_base(size_t size)
{
}
free(p);
void __cdecl free(void * pUserData)
{
}
void __cdecl _free_dbg(void* pUserData, int nBlockUse)
{
}
int __cdecl _CrtIsValidHeapPointer(const void* pUserData)
{
}
static int __cdecl CheckBytes(unsigned char* pb, unsigned char bCheck, size_t nSize) // bCheck的值是253, nSize的值是4
{
}
void __cdecl _free_base(void* pBlock)
{
}
int* a = new int[6];
void* operator new(unsigned int cb)
{
}
void* __cdecl _nh_malloc(size_t nSize, int nhFlag)
{
}
delete a;
void operator delete(void* pUserData)
{
}
class Person
{
public:
private:
};
int main()
{
}
Person* p = new Person();这句代码先调用
void* operator new(unsigned int cb)
{
}
后调用Person() { a = 1; b = 2.0; c = 'f'; }
delete p;这句代码调用
void operator delete(void* pUserData)
{
}
int main()
{
}
Debug调试程序:
char* p = new char; 这句代码使p的内容变成0x00382DE0
00382DE0
分析: CD是帮char占一个字节的位置, 4个FD作为内存界限的标志
cin >> p; 这句代码调用 istream& istream::operator>>(char* s)
如果你输入a[Enter], 则内存如下:
00382DE0
分析: Ox61是字符'a'的ASCII码, 0x00是operator>>加的'\0', 因为char* s是字符串, 要以'\0'结尾, p是实参, s是形参
cout << p; 这句代码调用 ostream& ostream::operator<<(const char* s)
执行完这句代码后, 屏幕并没有输出任何信息
delete p; 这句代码调用 void operator delete(void* pUserData)
在void __cdecl _free_dbg(void* pUserData, int nBlockUse)的第二个CheckBytes代码里面出现问题Debug Error,
选择“忽略”错误, 最终屏幕还是没有输出任何信息
Debug直接执行程序:
如果你输入a[Enter], 则会出现问题Debug Error
Release直接执行程序:
如果你输入a[Enter], 则会很好地输出a
如果你输入abcdefghijk[Enter], 则会很好地输出abcdefghijk
_CrtIsValidHeapPointer(pUserData)
在project setting里link里将general debug info去掉就可以了，不过根本问题是有悬空指针
所有的lib都要和主程序版本一样,如果是release，都是release,主程序是debug版本则无所谓
在VC++2005中使用Pwlib和Opal库，界面使用WinForm进行开发，编译选项为 /clr
编译、链接都没有问题，但启动程序时，出现运行时错误:
在网上搜了很久，发现很少有人提到该问题的解决办法，后来看到微软的论坛上，有人提出过这个bug，详情请看我的另外一篇文章：
_CrtIsValidHeapPointer
http://www.cnblogs.com/sunrack/articles/588115.html
原来导致该问题的原因是：
The reason why you get this error is that a winforms application has a managed entry point. The initialization of the native global objects is done by the CRT (C RunTime) startup routine. Since in this case there is no CRT startup routine the MyBoard global object fails to initialize correctly.
VC++开发组的人给出了一种折中的办法，
1. Set Linker\Advanced\Entry Point to "" (empty string)
2. Set Linker\System\Subsystem to Not Set
Step 1: Makes sure that the CRT startup code is invoked. This is because, if no entry point is specified, the linker will automatically use mainCRTStartup, which is defined in the CRT libraries. mainCRTStartup will make sure that the global object is initialized correctly.
Step 2: Makes sure that the linker will look for the symbol “main”. The linker looks for “main” because mainCRTStartup calls main() in its body. The default option for a Winforms application is Subsystem:Windows and this makes the linker look for WinMain().
虽然程序可以正常启动，但是却会在程序显示Winform的同时，出现一个console窗口，很是不爽。
不服输的我，继续到处找资料，查找了几乎网上所有的资源,在微软的官方文档中，该问题被定义为 load lock，即CLI和CRT的初始化死锁问题，
详见 我的另外一篇文章：
Initialization of Mixed Assemblies
http://www.cnblogs.com/sunrack/articles/592408.html
但是在该文档中提到的几种解决方法，经过测试，发现对我的这个问题均无作用。
后来找到在VC++2003中的解决初始化问题的文章，
详见 我的另外一篇文章：
Persisting View State Update, Using Managed Extensions in a DLL
http://www.cnblogs.com/sunrack/articles/593807.html
该文章详细介绍了VC++2003中的臭名昭著的load lock问题，并给出了解决办法，即自己写dll的初始化函数。
感觉到好像有了希望！！
根据文章介绍的另外一篇文章：
详见我的另外一篇文章：
Converting Managed Extensions for C++ Projects from Pure Intermediate Language to Mixed Mode
http://www.cnblogs.com/sunrack/articles/593847.html
我进行了大量测试，最后发现，VC++2005中的load lock问题，确实已经简化了很多，即已经确定化，最后我终于找到了解决方案：
解决方案：
在项目中添加CPP文件，其中定义一个托管类，其成员函数负责手动调用CRT的初始化。
注意，项目中只要有该CPP文件即可，不需要生成对象或者调用其成员函数。
该文件名称为ManagedWrapper.cpp，定义如下：
// ManagedWrapper.cpp// This code verifies that DllMain is not called by the Loader// automatically when linked with /noentry. It also checks some// functions that the CRT initializes.#include <</SPAN>windows.h>#include <</SPAN>stdio.h>#include <</SPAN>string.h>#include <</SPAN>stdlib.h>#include <</SPAN>math.h>#include "_vcclrit.h"#using <</SPAN>mscorlib.dll>using namespace System;public ref class ManagedWrapper
{
public: static int minitialize()
{ int retval = 0; try { __crt_dll_initialize();
} catch(System::Exception^ e) { Console::WriteLine(e); retval = 1; } return retval; } static int mterminate() { int retval = 0; try { __crt_dll_terminate(); } catch(System::Exception^ e) { Console::WriteLine(e); retval = 1; } return retval; }
};经过测试，一切OK！！！！
太爽了，终于可以抛开MFC那笨拙的界面开发工具！！
我现在可以充分利用Winform的快速界面开发功能，底层调用Pwli和Opal来开发视频会议了！
呵呵，我已经连续3天没有睡觉了，今晚终于可以做个好梦了！！
malloc和free在教材里不知讲了多少，今天实际用到一处，就出问题了。
案发现场是我用VC++在WINXP下编程，先看这一段代码
{
}
先声明一个指针，然后分配64字节给它。操作指针向后移动32字节，最后把这个指针free掉并设为NULL。这样虽然操作时的数据还留在内存区域里，但已经没有指针指向该区域，数据可以被后面的程序覆盖了。看起来没错吧？恩恩好象是没错, 抓了三个同事来问，全票通过.
而如果把代码改成
{
}
就没错了。李博士的解释是：malloc的时候系统创建了一个链表之类的东西，里面包含了起始地址和长度;而free的时候根据参数中的指针进行判断，如果该指针符合链表中某一节的起始地址，那么就把这一节free掉，如果去free一个不在链表中的地址，就出错啦。
比较好的处理方式是这样
{
}
即保留malloc时候的初始地址，然后赋给另外一个临时指针。操作时使用后者。free的时候把保留的起始指针free掉，而临时指针只是个变量，置空就可以了。
文章到这里似乎就应该写完了，不过由于johnathan的帮忙, 突然有了下文。
注意警告框中的_CrtIsValidHeapPointer,在MSDN上查到这个函数的说明为:
Verifies that a specified pointer is in the local heap (debug version only).
int _CrtIsValidHeapPointer(const void *userData);
Parameter：
userData
Return Value：
_CrtIsValidHeapPointer returns TRUE if the specified pointer is in the local heap. Otherwise, the function returns FALSE.
也就是说仅在debug版本中检查free参数是否为the beginning of an allocated memroy block.
那么就编译一个release版本，果然，运行通过, 没弹出什么警告或错误。但运行通过不等于正常无误,
那么结论就是：free掉非malloc起始地址的指针，在debug版本中会出错警告，而在release版本中不会弹出警告但仍然是有错的。所以，还是推荐使用第三段代码的用法
检查指针有效性
下面的示例使用 _CrtIsValidPointer 验证给定的内存范围对于读或写是否有效。
_ASSERTE(_CrtIsValidPointer( address, size, TRUE );
下面的示例使用 _CrtIsValidHeapPointer 验证指针指向本地堆（由 C 运行时库的这个实例创建和管理的堆；DLL 可以有它自己的库实例，因而也可以有它自己的、位于应用程序堆之外的堆）中的内存。该断言不仅捕捉空地址或超出边界的地址，还捕捉指向静态变量、堆栈变量和其他任何非本地内存的指针。
_ASSERTE(_CrtIsValidPointer( myData );
========
//从CSDN.NET
_CrtIsValidHeapPointer(pUserData)的问题:
如果是:Debug
如果“Assertion
The
代码一气呵成，但运行的时候会出现_CrtIsValidHeapPointer的异常，跟进去调了一上午的Bug，终于搞定
跟踪定位到 _CrtIsValidHeapPointer ，注意到 g 8h"@dbgheap.c 文件中 _CrtIsValidHeapPointer 处注释：
大概是因为 dll 如果静态链接了运行时库，dll 就会拥有独立于应用程序堆（也称作local heap）的运行时堆实例。此时在 dll 外部就不能访问此 local heap，所以也就有上面所出现的异常啦。MSDN 中也有介绍：
The _CrtIsValidHeapPointer function is used to ensure that a specific memory address is within the local heap. The local heap refers to the heap created and managed by a particular instance of the C run-time library. If a dynamic-link library (DLL) contains a static link to the run-time library, it has its own instance of the run-time heap, and therefore its own heap, independent of the application's local heap. When _DEBUG is not defined, calls to _CrtIsValidHeapPointer are removed during preprocessing.
程序崩溃在当析构一个带有vector成员函数对象的时候，在析构vector时，会出现这个错误，大致原因是因为析构的时候找不到vector分配的空间
一行一行查看代码发现，对象里面的points2, status等vector变量是在calcOpticalFlowPyrLK(img1, img2, points1, points2, status, similarity, window_size, level, term_criteria, lambda, 0); 函数中分配的，即opencv的dll，所以当对象进行析构的时候，因为不能访问此local heap所以会有异常崩溃。
解决方法：
在调用opencv的函数之前，自己进行空间的分配