VC++ 之常见内存异常值

0　VC++ 常见的内存异常值

* 0xcccccccc : Used by Microsoft's C++ Debugging runtime library to mark uninitialised stack memory

* 0xcdcdcdcd : Used by Microsoft's C++ Debugging runtime library to mark uninitialised heap memory

* 0xfeeefeee : Used by Microsoft's HeapFree() to mark freed heap memory

* 0xabababab : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory

* 0xabadcafe : A startup to this value to initialize all free memory to catch errant pointers

* 0xbaadf00d : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory

* 0xbadcab1e : Error Code returned to the Microsoft eVC Debugger when connection is severed to the Debugger

* 0xbeefcace : Used by Microsoft .NET as a magic number in resource files

　　以上异常值，比较常见的为前三种：

　　对于0xcccccccc和0xcdcdcdcd，在 Debug 模式下，VC 会把未初始化的栈内存上的指针全部填成 0xcccccccc ，当字符串看就是 “烫烫烫烫……”；会把未初始化的堆内存上的指针全部填成 0xcdcdcdcd，当字符串看就是 “屯屯屯屯……”。那么调试器为什么要这么做呢？VC的DEBUG版会把未初始化的指针自动初始化为0xcccccccc或0xcdcdcdcd，而不是就让取随机值，那是为了方便我们调试程序，如果野指针的初值不确定，那么每次调试同一个程序就可能出现不一样的结果，比如这次程序崩掉，下次却能正常运行，这样显然对我们解bug是非常不利的，所以自动初始化的目的是为了让我们一眼就能确定我们使用了未初始化的野指针了。

　　对于0xfeeefeee，是用来标记堆上已经释放掉的内存。注意，如果指针指向的内存被释放了，变量本身的地址如未做改动，还是之前指向的内存的地址。如果该指针是一个类的指针，并且类中包含有指针变量，则内存被释放后（对于C++类，通常是执行delete操作），类中的指针变量就会被赋值为0xfeeefeee。如果早调试代码过程中，发现有值为0xfeeefeee的指针，就说明对应的内存被释放掉了，我们的代码已经出问题了。

　　在此，就有一个关于VC 中 Debug和Release模式下的变量初始化问题

　　大家都知道，Debug跟Release在初始化变量时所做的操作是不同的，Debug是将每个字节位都赋成0xcc，而Release的赋值近似于随机(我想是直接从内存中分配的，没有初始化过)。这样就明确了，如果你的程序中的某个变量没被初始化就被引用，就很有可能出现异常：用作控制变量将导致流程导向不一致；用作数组下标将会使程序崩溃；更加可能是造成其他变量的不准确而引起其他的错误。所以，在声明变量后马上对其初始化一个默认的值是最简单有效的办法，否则项目大了你找都没地方找。代码存在错误在Debug方式下可能会忽略而不被察觉到，如Debug方式下数组越界也大多不会出错，在 Release中就暴露出来了，这个找起来就比较难了。

1 VC++ 之Debug运行正常，Release运行崩溃

　　I、内存分配问题

　　1.变量未初始化。

　　在Debug中会自动给变量初始化，而在Release中则不会。所以：尽可能的给变量、类或结构初始化（很重要！）。

　　2.数据溢出的问题

　　如：

　　char buffer[10];

　　int counter;

　　lstrcpy(buffer, "abcdefghik");

　　如果您使用了strcpy(),lstrcpy() 等函数请注意检查。

　　在Debug版中buffer的NULL覆盖了counter的高位，但是除非counter>16M，什么问题也没有。但是在Release版中，counter可能被放在寄存器中，这样NULL就覆盖了buffer下面的空间，可能就是函数的返回地址，这将导致ACCESS ERROR。

　　3.Debug版和Release版的内存分配方式是不同的。

　　如果你在Debug版中申请ele 为 6*sizeof(DWORD)=24bytes,实际上分配给你的是32bytes（Debug版以32bytes为单位分配），而在Release版，分配给你的就是24bytes（Release版以8bytes为单位），所以在Debug版中如果你写ele[6]，可能不会有什么问题，而在Release版中，就有ACCESS VIOLATE。

　　II.ASSERT和VERIFY

　　1.ASSERT在Release版本中是不会被编译的。

　　假如你在这些语句中加了程序中必须要有的代码,

　　比如：

　　ASSERT(pNewObj = new CMyClass);

　　pNewObj->MyFunction();

　　这种时候Release版本中的pNewObj不会分配到空间所以执行到下一个语句的时候程序会报该程序执行了非法操作的错误。这时可以用 VERIFY

　　III.参数问题：

　　自定义消息的处理函数，必须定义如下：

　　afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);

　　返回值必须是HRESULT型，否则Debug会过，而Release出错

　　IV. 内存分配

　　保证数据创建和清除的统一性：如果一个DLL提供一个能够创建数据的函数，那么这个DLL同时应该提供一个函数销毁这些数据。数据的创建和清除应该在同一个层次上。

　　V.DLL的灾难

　　人们将不同版本DLL混合造成的不一致性形象的称为 “动态连接库的地狱“(DLL Hell)如果你的程序使用你自己的DLL时请注意：

　　1.不能将Debug和Release版的DLL混合在一起使用。Debug都是Debug版，Release版都是Release版。

　　2.千万不要以为静态连接库会解决问题，那只会使情况更糟糕

　　VI.RELEASE板中的调试：

　　1.将ASSERT() 改为 VERIFY() 。

　　找出定义在"#ifdef _DEBUG"中的代码，如果在RELEASE版本中需要这些代码请将他们移到定义外。查找TRACE(...)中代码，因为这些代码在RELEASE中也不被编译。请认真检查那些在RELEASE中需要的代码是否并没有被编译。

　　2.变量的初始化所带来的不同。

　　在不同的系统，或是在DEBUG/RELEASE版本间都存在这样的差异，所以请对变量进行初始化。

　　3.是否在编译时已经有了警告?

　　请将警告级别设置为3或4, 然后保证在编译时没有警告出现.

　　VII.将Project Settings" 中 "C++/C " 项目下优化选项改为Disbale（Debug）。

　　编译器的优化可能导致许多意想不到的错误，请参考

　　http://www.pgh.net/~newcomer/Debug_Release.htm

　　1.此外对RELEASE版本的软件也可以进行调试

　　请做如下改动：

　　在"Project Settings" 中 "C++/C " 项目下设置 "category" 为 "General" 并且将"Debug Info"设置为 "Program Database"。

　　在"Link"项目下选中"Generate Debug Info"检查框。

　　"Rebuild All" 如此做法会产生的一些限制: 无法获得在MFC DLL中的变量的值。必须对该软件所使用的所有DLL工程都进行改动