debug调试运行正常但在release模式下退出程序时报错

上传人:cl****1 文档编号:457362277 上传时间:2024-01-10 格式:DOC 页数:17 大小:60KB
返回 下载 相关 举报
debug调试运行正常但在release模式下退出程序时报错_第1页
第1页 / 共17页
debug调试运行正常但在release模式下退出程序时报错_第2页
第2页 / 共17页
debug调试运行正常但在release模式下退出程序时报错_第3页
第3页 / 共17页
debug调试运行正常但在release模式下退出程序时报错_第4页
第4页 / 共17页
debug调试运行正常但在release模式下退出程序时报错_第5页
第5页 / 共17页
点击查看更多>>
资源描述

《debug调试运行正常但在release模式下退出程序时报错》由会员分享,可在线阅读,更多相关《debug调试运行正常但在release模式下退出程序时报错(17页珍藏版)》请在金锄头文库上搜索。

1、Debug调试运行正常,但在Release模式下退由程序时报错Debug调试运行正常,但在Release模式下退由程序时报错分类:C/C+Windows编程2012-08-3012:43641人阅读评论(0)收藏举报优化编译器librarymfc多线程exception在最近的H.265分析器项目中,由现了一个问题,就是在Debug模式下运行正常,但是在Release模式下时,退由程序时,会报由以下错误:theinstructionat0x78d80f87”referencedmemoryat0x70665f70thememorycouldnotberead。在Release调试状态下,由现一

2、个提示First-chanceexceptionat0x7c96f749inH.265Anayer.exe:0xC0000005:Accessviolationreadinglocation0x385f735d.调试了很久都没有找到错误的所在,在网上找了一些资料,基本上确定应该是Release优化过程中造成了内存分配与释放发生了错误,但是还是没有找到具体的代码位置,纠结中,所以先记录下来这个问题。下面是网上找的一些这方面的介绍:http:/ .RuntimeLibrary:链接哪种运行时刻函数库通常只对程序的性能产生影响。调试版本的RuntimeLibrary包含了调试信息,并采用了一些保护机

3、制以帮助发现错误,因此性能不如发布版本。编译器提供的RuntimeLibrary通常很稳定,不会造成Release版错误;倒是由于Debug的RuntimeLibrary加强了对错误的检测,如堆内存分配,有时会由现Debug有错但Release正常的现象。应当指由的是,如果Debug有错,即使Release正常,程序肯定是有Bug的,只不过可能是Release版的莫次运行没有表现由来而已。2 .优化:这是造成错误的主要原因,因为关闭优化时源程序基本上是直接翻译的,而打开优化后编译器会作由一系列假设。这类错误主要有以下几种:1.帧指针(FramePointer)省略(简称FPO):在函数调用过程

4、中,所有调用信息(返回地址、参数)以及自动变量都是放在栈中的。若函数的声明与实现不同(参数、返回值、调用方式),就会产生错误???但Debug方式下,栈的访问通过EBP寄存器保存的地址实现,如果没有发生数组越界之类的错误(或是越界“不多”),函数通常能正常执行;Release方式下,优化会省略EBP栈基址指针,这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。C的强类型特性能检查由大多数这样的错误,但如果用了强制类型转换,就不行了。你可以在Release版本中强制加入/Oy-编译选项来关掉帧指针省略,以确定是否此类错误。此类错误通常有:MFC消息响应函数书写错误。正确的应为:afx_m

5、sgLRESULTOnMessageOwn(WPARAMwparam,LPARAMIparam);ON_MESSAGE宏包含强制类型转换。防止这种错误的方法之一是重定义ON_MESSAGE宏,把下列代码加到stdafx.h中(在#include“afxwin.h”之噩颜原形错误时编译会报错。#undefON_MESSAGE#defineON_MESSAGE(message,memberFxn)message,0,0,0,AfxSig_lwl,(AFX_PMSG)(AFX_PMSGW)(static_cast(&memberFxn),2. volatile型变量:volatile告诉编译

6、器该变量可能被程序之外的未知方式修改(如系统、其他进程和线程)。优化程序为了使程序性能提高,常把一些变量放在寄存器中(类似于register关键字),而其他进程只能对该变量所在的内存进行修改,而寄存器中的值没变。如果你的程序是多线程的,或者你发现莫个变量的值与预期的不符而你确信已正确的设置了,则很可能遇到这样的问题。这种错误有时会表现为程序在最快优化由错而最小优化正常。把你认为可疑的变量加上volatile试试。3.变量优化:优化程序会根据变量的使用情况优化变量。例如,函数中有一个未被使用的变量,在Debug版中它有可能掩盖一个数组越界,而在Release版中,这个变量很可能被优化调,此时数组

7、越界会破坏栈中有用的数据。当然,实际的情况会比这复杂得多。与此有关的错误有:非法访问,包括数组越界、指针错误等。例如voidfn(void)(inti;i=1;inta4;(intj;j=1;)a-1=1;/当然错误不会这么明显,例如下标是变量a4=1;)j虽然在数组越界时已由了作用域,但其空间并未收回,因而i和j就会掩盖越界。而Release版由于i、j并未具很大作用可能会被优化掉,从而使栈被破坏。3. _DEBUG与NDEBUG:当定义了_DEBUG时,assert()函数会被编译,而NDEBUG时不被编译。除此之外,VC中还有一系列断言宏。这包括:断言类型定义ANSIC断言voidass

8、ert(intexpression);CRuntimeLib断言_ASSERT(booleanExpression);_ASSERTE(booleanExpression);MFC断言ASSERT(booleanExpression);VERIFY(booleanExpression);ASSERT_VALID(pObject);ASSERT_KINDOF(classname,pobject);ATL断言ATLASSERT(booleanExpression);此外,TRACE()宏的编译也受DEBUG控制所有这些断言都只在Debug版中才被编译,而在Release版中被忽略。唯一的例外是VE

9、RIFY()o事实上,这些宏都是调用了assert()函数,只不过附加了一些与库有关的调试代码。如果你在这些宏中加入了任何程序代码,而不只是布尔表达式(例如赋值、能改变变量值的函数调用等),那么Release版都不会执行这些操作,从而造成错误。初学者很容易犯这类错误,查找的方法也很简单,因为这些宏都已在上面列由,只要利用VC的FindinFiles功能在工程所有文件中找到用这些宏的地方再一一检查即可。另外,有些高手可能还会加入#ifdef_DEBUG之类的条件编译,也要注意一下。顺便值得一提的是VERIFY()宏,这个宏允许你将程序代码放在布尔表达式里。这个宏通常用来检查WindowsAPI的

10、返回值。有些人可能为这个原因而滥用VERIFY(),事实上这是危险的,因为VERIFY()违反了断言的思想,不能使程序代码和调试代码完全分离,最终可能会带来很多麻烦。因此,专家们建议尽量少用这个宏。4. /GZ选项:这个选项会做以下这些事:1.初始化内存和变量。包括用0xCC初始化所有自动变量,0xCD(ClearedData)初始化堆中分配的内存(即动态分配的内存,例如new),0xDD(DeadData)填充已被释放的堆内存(例如delete),0xFD(deFencdeData)初始化受保护的内存(debug版在动态分配内存的前后加入保护内存以防止越界访问),其中括号中的词是微软建议的助

11、记词。这样做的好处是这些值都很大,作为指针是不可能的(而且32位系统中指针很少是奇数值,在有些系统中奇数的指针会产生运行时错误),作为数值也很少遇到,而且这些值也很容易辨认,因此这很有利于在Debug版中发现Release版才会遇到的错误。要特别注意的是,很多人认为编译器会用0来初始化变量,这是错误的(而且这样很不利于查找错误)2 .通过函数指针调用函数时,会通过检查栈指针验证函数调用的匹配性。(防止原形不匹配)3 .函数返回前检查栈指针,确认未被修改。(防止越界访问和原形不匹配,与第二项合在一起可大致模拟帧指针省略FPO)通常/GZ选项会造成Debug版由错而Release版正常的现象,因为

12、Release版中未初始化的变量是随机的,这有可能使指针指向一个有效地址而掩盖了非法访问除此之外,/Gm/GF等选项造成错误的情况比较少,而且他们的效果显而易见,比较容易发现。怎样“调试”Relea诚的程序遇到Debug成功但Release失败,显然是一件很沮丧的事,而且往往无从下手。如果你看了以上的分析,结合错误的具体表现,很快找生了错误,固然很好。但如果一时找不出,以下给生了一些在这种情况下的策略。1 .前面已经提过,Debug和Release只是一组编译选项的差别,实际上并没有什么定义能区分二者。我们可以修改Release版的编译选项来缩小错误范围。如上所述,可以把Release的选项逐

13、个改为与之相对的Debug选项,如/MD改为/MDd、/O1改为/Od,或运行时间优化改为程序大小优化。注意,一次只改一个选项,看改哪个选项时错误消失,再对应该选项相关的错误,针对性地查找。这些选项在Settings中都可以直接通过列表选取,通常不要手动修改。由于以上的分析已相当全面,这个方法是最有效的。2 .在编程过程中就要时常注意测试Release版本,以免最后代码太多,时间又很紧。3 .在Debug版中使用/W4警告级别,这样可以从编译器获得最大限度的错误信息,比如if(i=0)就会引起/W4善告。不要忽略这些警告,通常这是你程序中的Bug引起的。但有时/W4会带来很多冗余信息,如未使用的函数参数警告,而很多消息处理函数都会忽略莫些参数。我们可以用:#progmawarning(disable:4702)

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 演讲稿/致辞

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号