vc中debug版程序正常但release版崩溃的解决方法

I. 内存分配问题

1. 变量未初始化。

为debug中会自动给变量初始化found=FALSE,而在release版中

则不会。所以尽可能的给变量、类或结构初始化。

2. 数据溢出的问题

如：char buffer[10];

int counter;

lstrcpy(buffer, "abcdefghik");

在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版中，就有A

CCESS 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提供一个能够创建数据的函数，那么这个D

LL同时应该提供一个函数销毁这些数据。数据的创建和清除应该在同一个层次上。

V. DLL的灾难

人们将不同版本DLL混合造成的不一致性形象的称为 “动态连接库的地狱“(DLL Hell)

如果你的程序使用你自己的DLL时请注意：

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

e版都是release版。

解决办法是将debug和release的程序分别放在主程序的debug和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/deb

ug_release.htm

1. 此外对RELEASE版本的软件也可以进行调试，请做如下改动：

在"Project Settings" 中 "C++/C " 项目下设置 "category" 为 "General" 并且将"D

ebug Info"设置为 "Program Database"。

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

"Rebuild All"

如此做法会产生的一些限制：

无法获得在MFC DLL中的变量的值。

必须对该软件所使用的所有DLL工程都进行改动。

=========================================================

例子：

作为Windows程序员，平时最担心见到的事情可能就是程序发生了崩溃（异常），这时Windows会提示该程序执行了非法操作，即将关闭。请与您的供应商联系。呵呵，这句微软的“名言”，恐怕是程序员最怕见也最常见的东西了。

在一个大型软件的测试过程中，初期出现程序崩溃似乎成了不可避免的事。其实测试中出现程序崩溃并不可怕，反而是测试的成功。作为开发的我们更需要关心的是程序中的哪个函数或哪一行导致了系统崩溃，这样才能有针对性的进行改正。
本文描述了自己总结的几种定位崩溃的办法。 案例分析

以下是几种常见的崩溃现象及对应的处理办法：
1． 对于Release版本必现的崩溃且在Debug版本上也崩溃的程序。
解决思路：去掉所有断点，直接在Debug版本上运行程序，在程序崩溃时，VC会自动跳转定位到崩溃代码行， 这种方法最简单也最常用。
2． 对于在Debug版本上不崩溃但Release版本崩溃的程序，很有可能是Debug和Release版本的差异。例如Debug版本所有成员在构造时会被清0，而Release版本所有成员在构造时是内存里面的原始值，而且Debug有运行时库做保护，这些都会导致某些程序在Debug正常而Release崩溃。
解决思路：1）在程序中加打印，通过程序崩溃之前的打印定位出错位置； 2）逐段注释代码，直到程序不崩溃为止。这种方法耗时较长，对程序员要求较高，而且对于那种不是必现的bug或者很难搭建执行环境的情况就较难处理了。
3． 对于在客户现场崩溃的情况，显然不适合直接带一台电脑去调试。
解决思路：应该有文件记录下崩溃信息，客服人员可以将崩溃信息文件发送给程序员，以便程序员查询崩溃原因，然后利用编译时生成MAP文件（工程信息文件，存放在版本编译机中）的信息来定位问题函数或问题代码行。下面就这种方法展开讨论一

对于上节第三种情况，也是最难解决的情况，解决过程如下：
1. 崩溃回调注册，拦截Windows程序崩溃；
2. 在回调处理中，输出崩溃原因，崩溃内存地址，崩溃堆栈；
3. 工程输出map文件；
4. 通过崩溃内存地址以及map文件找出崩溃的函数。
5. 使用COD文件精确定位崩溃行

崩溃回调注册

实际上，只靠Windows的错误消息对话框提供的信息量是很有限的。用SetUnhandledExceptionFilter注册自定义错误处理回调函数，可以替换Win32默认的异常处理过滤器(top-level exception filter)，而且能打印出崩溃堆栈，这对定位崩溃原因非常有用。
SetUnhandledExceptionFilter的函数原型：

LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter( LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter );

功 能：注册和注销异常处理回调；
用 法：第一次调用注册异常处理回调，第二次调用注销；
返回值：返回当前的exception filter。需要保存这个函数指针，在注销异常处理回调的时候，以此为参数再次调用SetUnhandledExceptionFilter。打印异常处理也需要此值。
参数： 异常处理的回调函数；

3出崩溃信息

崩溃信息在异常回调函数中打印，输出到程序执行目录下的文件：
异常处理回调的函数原形：

LONG WINAPI CallBackDebugInfo ( EXCEPTION_POINTERS *pException);

功 能：异常处理回调处理，打印崩溃信息；
用 法：注册自定义错误处理回调：SetUnhandledExceptionFilter (CallBackDebugInfo)；
返回值：EXCEPTION_CONTINUE_EXECUTION – 错误已经被修复,从异常发生处继续执行
EXCEPTION_CONTINUE_SEARCH – 继续查找异常过滤器
EXCEPTION_EXECUTE_HANDLER – 正常返回
参数： 崩溃信息结构，包含崩溃原因、崩溃模块、崩溃地址、崩溃堆栈等；
常见崩溃原因有：
EXCEPTION_ACCESS_VIOLATION = C0000005h 读写内存错误
EXCEPTION_INT_DIVIDE_BY_ZERO = C0000094h 除0错误
EXCEPTION_STACK_OVERFLOW = C00000FDh 堆栈溢出或者越界
EXCEPTION_GUARD_PAGE = 80000001h 由Virtual Alloc建立起来的属性页冲突
EXCEPTION_NONCONTINUABLE_EXCEPTION = C0000025h不可持续异常,程序无法恢复执行,异常处理例程不应处理这个异常
EXCEPTION_INVALID_DISPOSITION = C0000026h在异常处理过程中系统使用的代码
EXCEPTION_BREAKPOINT = 80000003h 调试时中断（INT 3）
EXCEPTION_SINGLE_STEP = 80000004h 单步调试状态(INT 1)

3.3 输出map文件

map文件记录程序的全局符号、源文件和代码行号信息，是整个程序工程信息的静态文本。通过文本阅读工具如Ultra Edit或记事本就可以打开Map文件。
在 VC 中，打开“Project Settings”选项页，选择 C/C++ 选项卡，并在最下面的 Project Options 里面输入：/Zd ，然后选择 Link 选项卡，选中“Generate mapfile”复选框。并在最下面的 Project Options里面输入：/mapinfo:lines，表示生成 map 文件时，加入行信息。


最后编译就可以生成 MAP 文件，可以在工程的Debug或Release目录下找到刚刚生成的MAP文件，文件名为“工程名.map”。

3.4 使用map文件找出崩溃函数

　　 　通过上面的步骤，已经得到了 MAP 文件，那么我们该如何利用它呢？下面一步步演示使用MAP文件定位程序崩溃行的过程。
1.我们先在代码中加入非法内存操作（最常见的异常）的代码：

BOOL CMainFrameDlg::OnInitDialog() { ::SetProp(m_hWnd, AfxGetApp()->m_pszExeName, (HANDLE)1); s32 *p = NULL; *p= 123;

2.执行程序，程序在开始就异常，在异常打印文件中打印了如下信息：

======================== 崩溃信息 ========================== 崩溃时间： 2009/06/02 16:58:22 崩溃原因： 非法内存操作 异常代码 = c0000005 异常地址 = 0x0045a76f 异常模块: E:\ccroot\liuxiaojing_Enterprise\Enterprise_VOB\70-nms1\pcmt2\prj_win32\Release\pcmt2.exe Section name: .text - offset(rva) : 0x0005976f ---------------------- Trips of Stack ---------------------- E:\ccroot\liuxiaojing_Enterprise\Enterprise_VOB\70-nms1\pcmt2\prj_win32\Release\pcmt2.exe name : pcmtver - location: 2bef

3. 确定崩溃地址是：0x0005976f，在Map文件中定位函数：

0001:00059420 ?OnCreate@CMainFrameDlg@@IAEHPAUtagCREATESTRUCTA@@@Z 0045a420 f MainFrameDlg.obj 0001:00059460 ?SetTooltips@CMainFrameDlg@@AAEXXZ 0045a460 f MainFrameDlg.obj 0001:00059700 ?OnTranslate@CMainFrameDlg@@IAEJIJ@Z 0045a700 f MainFrameDlg.obj 0001:00059730 ?OnInitDialog@CMainFrameDlg@@MAEHXZ 0045a730 f MainFrameDlg.obj 0001:00059a10 ?OnSysCommand@CMainFrameDlg@@IAEXIJ@Z 0045aa10 f MainFrameDlg.obj 0001:00059c20 ?OnPaint@CMainFrameDlg@@IAEXXZ 0045ac20 f MainFrameDlg.obj

根据00059730< 0005976f < 00059a10 ，确定是在CMainFrameDlg 的OnInitDialog函数中的某一行产生了异常。

3.5 使用map代码行定位崩溃行区间

Line numbers for .\Release\MainFrameDlg.obj(E:\ccroot\liuxiaojing_Enterprise\Enterprise_VOB\70-nms1\pcmt2\source\MainFrameDlg.cpp) segment .text 498 0001:00059647 499 0001:00059667 501 0001:0005966e 502 0001:000596af 503 0001:000596ed 506 0001:00059700 507 0001:00059703 508 0001:00059708 510 0001:0005970f 511 0001:00059720 512 0001:00059723 515 0001:00059730 516 0001:0005974e 521 0001:0005976d 524 0001:0005977e 526 0001:0005978b

我们在map文件的代码行信息里查找不超过计算结果0x0005976f，但可以找最接近的数。发现是MainFrameDlg.cpp 文件中的：521 0001:0005976d，而程序实际崩溃行在519（注释行和空行也要计算在内），非常接近实际崩溃行了，考虑到程序实际执行的是汇编指令，我们可以在(516 ~524)行区间内寻找到实际崩溃行。
　　

3.6 无法定位崩溃的情况

但是这种输出文件的方法也不能定位所有崩溃问题，俗话说得好：没有万能的救世主。
例如我们有时会碰到下层编解码器崩溃，崩溃打印如下表：

======================== 崩溃信息 ========================== 崩溃时间： 2009/05/07 09:48:17 崩溃原因： 非法内存操作 异常代码 = c0000005 异常地址 = 0x02163b32 异常模块: C:\WINDOWS\system32\kdg7221.acm Section name: .text - offset(rva) : 0x00002b32 ---------------------- Trips of Stack ---------------------- C:\WINDOWS\system32\kdg7221.acm

这时可以看出是我们的音频解码器kdg7221.acm崩溃了，此时就要考虑我们的音频编解码参数是否设置错了，如果没有设错，bug可以转到媒体处理层或者软件一部处理。