一、Debug和Release编译方式的本质区别
Debug通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。Release称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。 Debug和Release的真正秘密,在于一组编译选项。下面列出了分别针对二者的选项(当然除此之外还有其他一些,如/Fd/Fo,但区别并不重要,通常他们也不会引起Release版错误,在此不讨论)
Debug版本: /MDd/MLd或/MTd使用Debugruntimelibrary(调试版本的运行时刻函数库) /Od关闭优化开关 /D"_DEBUG"相当于#define_DEBUG,打开编译调试代码开关(主要针对assert函数) /ZI创建Editandcontinue(编辑继续)数据库,这样在调试过程中如果修改了源代码不需重新编译 /GZ可以帮助捕获内存错误 /Gm打开最小化重链接开关,减少链接时间
Release版本: /MD/ML或/MT使用发布版本的运行时刻函数库 /O1或/O2优化开关,使程序最小或最快 /D"NDEBUG"关闭条件编译调试代码开关(即不编译assert函数) /GF合并重复的字符串,并将字符串常量放到只读内存,防止被修改
实际上,Debug和Release并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动。事实上,我们甚至可以修改这些选项,从而得到优化过的调试版本或是带跟踪语句的发布版本。
二、哪些情况下Release版会出错
有了上面的介绍,我们再来逐个对照这些选项看看Release版错误是怎样产生的
1.RuntimeLibrary:链接哪种运行时刻函数库通常只对程序的性能产生影响。调试版本的RuntimeLibrary包含了调试信息,并采用了一些保护机制以帮助发现错误,因此性能不如发布版本。编译器提供的RuntimeLibrary通常很稳定,不会造成Release版错误;倒是由于Debug的RuntimeLibrary加强了对错误的检测,如堆内存分配,有时会出现Debug有错但Release正常的现象。应当指出的是,如果Debug有错,即使Release正常,程序肯定是有Bug的,只不过可能是Release版的某次运行没有表现出来而已。
2.优化:这是造成错误的主要原因,因为关闭优化时源程序基本上是直接翻译的,而打开优化后编译器会作出一系列假设。这类错误主要有以下几种:
(1)帧指针(FramePointer)省略(简称FPO):在函数调用过程中,所有调用信息(返回地址、参数)以及自动变量都是放在栈中的。若函数的声明与实现不同(参数、返回值、调用方式),就会产生错误————但Debug方式下,栈的访问通过EBP寄存器保存的地址实现,如果没有发生数组越界之类的错误(或是越界“不多”),函数通常能正常执行;Release方式下,优化会省略EBP栈基址指针,这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。C++的强类型特性能检查出大多数这样的错误,但如果用了强制类型转换,就不行了。你可以在Release版本中强制加入/Oy-编译选项来关掉帧指针省略,以确定是否此类错误。此类错误通常有:
●MFC消息响应函数书写错误。正确的应为 afx_msgLRESULTOnMessageOwn(WPARAMwparam,LPARAMlparam); 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<LRESULT(AFX_MSG_CALL/ CWnd::*)(WPARAM,LPARAM)>(&memberFxn)},
(2)volatile型变量:volatile告诉编译器该变量可能被程序之外的未知方式修改(如系统、其他进程和线程)。优化程序为了使程序性能提高,常把一些变量放在寄存器中(类似于register关键字),而其他进程只能对该变量所在的内存进行修改,而寄存器中的值没变。如果你的程序是多线程的,或者你发现某个变量的值与预期的不符而你确信已正确的设置了,则很可能遇到这样的问题。这种错误有时会表现为程序在最快优化出错而最小优化正常。把你认为可疑的变量加上volatile试试。
(3)变量优化:优化程序会根据变量的使用情况优化变量。例如,函数中有一个未被使用的变量,在Debug版中它有可能掩盖一个数组越界,而在Release版中,这个变量很可能被优化调,此时数组越界会破坏栈中有用的数据。当然,实际的情况会比这复杂得多。与此有关的错误有: ●非法访问,包括数组越界、指针错误等。例如 voidfn(void) { inti; i=1; inta[4]; { intj; j=1; } a[-1]=1;//当然错误不会这么明显,例如下标是变量 a[4]=1; } j虽然在数组越界时已出了作用域,但其空间并未收回,因而i和j就会掩盖越界。而Release版由于i、j并未其很大作用可能会被优化掉,从而使栈被破坏。
3._DEBUG与NDEBUG:当定义了_DEBUG时,assert()函数会被编译,而NDEBUG时不被编译。除此之外,VC++中还有一系列断言宏。这包括:
ANSIC断言voidassert(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版中被忽略。唯一的例外是VERIFY()。事实上,这些宏都是调用了assert()函数,只不过附加了一些与库有关的调试代码。如果你在这些宏中加入了任何程序代码,而不只是布尔表达式(例如赋值、能改变变量值的函数调用等),那么Release版都不会执行这些操作,从而造成错误。初学者很容易犯这类错误,查找的方法也很简单,因为这些宏都已在上面列出,只要利用VC++的FindinFiles功能在工程所有文件中找到用这些宏的地方再一一检查即可。另外,有些高手可能还会加入#ifdef_DEBUG之类的条件编译,也要注意一下。 顺便值得一提的是VERIFY()宏,这个宏允许你将程序代码放在布尔表达式里。这个宏通常用来检查WindowsAPI的返回值。有些人可能为这个原因而滥用VERIFY(),事实上这是危险的,因为VERIFY()违反了断言的思想,不能使程序代码和调试代码完全分离,最终可能会带来很多麻烦。因此,专家们建议尽量少用这个宏。
4./GZ选项:这个选项会做以下这些事
(1)初始化内存和变量。包括用0xCC初始化所有自动变量,0xCD(ClearedData)初始化堆中分配的内存(即动态分配的内存,例如new),0xDD(DeadData)填充已被释放的堆内存(例如delete),0xFD(deFencdeData)初始化受保护的内存(debug版在动态分配内存的前后加入保护内存以防止越界访问),其中括号中的词是微软建议的助记词。这样做的好处是这些值都很大,作为指针是不可能的(而且32位系统中指针很少是奇数值,在有些系统中奇数的指针会产生运行时错误),作为数值也很少遇到,而且这些值也很容易辨认,因此这很有利于在Debug版中发现Release版才会遇到的错误。要特别注意的是,很多人认为编译器会用0来初始化变量,这是错误的(而且这样很不利于查找错误)。 (2)通过函数指针调用函数时,会通过检查栈指针验证函数调用的匹配性。(防止原形不匹配) (3)函数返回前检查栈指针,确认未被修改。(防止越界访问和原形不匹配,与第二项合在一起可大致模拟帧指针省略FPO)
通常/GZ选项会造成Debug版出错而Release版正常的现象,因为Release版中未初始化的变量是随机的,这有可能使指针指向一个有效地址而掩盖了非法访问。
除此之外,/Gm/GF等选项造成错误的情况比较少,而且他们的效果显而易见,比较容易发现。
|
相关推荐
很多时候在写代码过程中,发现 Debug 下运行正常,Release 下就会出现问题,百思不得其解,而Release 下又无法进行调试,于是只能采用printf方式逐步定位到问题所在处,才发现原来是给定的一个数组未初始化,导致...
Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员...下面列出了分别针对二者的选项(当然除此之外还有其他一些,如/Fd /Fo,但区别并不重要,通常他们也不会引起 Release 版错误,在此不讨论)
1.内存分配问题 2.ASSERT和VERIFY 3.参数问题 4.DLL的灾难 5.RELEASE板中的调试 6.编译器的优化可能导致许多意想不到的错误
当调试VC 程序时,经常出现release 版本或者debug版本运行崩溃的问题,本文给出了一些解决方法……
不知道你遇到过没有? 埋头编写代码,一直在debug下调试...一转到Release版,一堆莫明其妙的错误就来了。 之前的哪些改动造成的异常也无从查起。这怎么办? 看了这篇文章,你也许就能对症下药地解决你面临的难题了。
其他release版、MFC程序什么的都是拷redist下相应文件夹下的文件就可以了,文件夹后都有标识! 方法二: 修改编译选项,将/MD或/MDd 改为 /MT或/MTd,这样就实现了对VC运行时库的静态链接,在运行时就不再需要VC的...
本文为大家讲解了项目发布Debug和Release版的区别,供大家参考,具体内容如下 一、Debug和Release的区别 Debug:调试版本,包含调试信息,所以容量比Release大很多,并且不进行任何优化(优化会使调试复杂化,因为源...
在VS2015 MFC GDI+下开发的精美温度表盘控件类静态库(DEBUG RELEASE 版) 可通过定义静态库中的类,显示、设置 温度表盘显示,并可设置控件窗口位置、大小和表盘上各显示区域的位置、弧度。温度显示同时有指针标识和...
win8.1下编译opencv3.4.1+cmake+contrib的debug和release文件
手动删除Debug目录很累,就自己写了个自动删除Debug目录的程序,觉得挺好用的,有需要的可以下载试试。
vs90(vs2008) sp1 64位运行库,包括Debug和Release版程序,都可以运行,vs2008编译的程序或者vs2008sp1编译的程序都可以运行。
程序在debug可以正常运行,但是在release版后异常结束,系统又没有提供任何信息情况下,或者程序发布后在客户手中出现异常崩溃,但自己测试又不能复现问题,要是能捕获到异常时相关信息就很好定位问题了。...
在使用VC开发软件的过程中,正当要享受那种兴奋的时候突然发现:release与debug运行结果不一致,甚至出错,而release又不方便调试,真的是当头一棒啊,可是疼归疼,问题总要解决,下面将讲述一下我的几点经验,看看...
DebugTrack 是调试输出字符串追踪工具,它可以非常方便准确地监视程序中使用 Windows API OutputDebugString 输出的字符串。 DebugTrack 是一个免费软件,你可以无偿地使用它的所有功能,甚至可以向作者索要源...
完整的俄罗斯方块C#源程序,运行程序时将目录下的images和sounds文件夹拷贝到bin/debug或者bin/Release目录下,否则运行时会找不到文件。
大家知道,VC可以用来调试程序,除了调试Debug程序,当然也可以调试Release程 序(调试Release程序时为汇编代码)。如果知道函数的入口地址,只需在函数入口上设置断点,当程序调用了设置断点的函数时,VC就会暂停...
4. 尽管可执行文件位于RELEASE和DEBUG子目录,但有些程序还使用了其父目录下的数据文件,目录名与程序名相同,其中包含程序的源代码。因此,在此程序运行时或程序运行不正常时,默认目录一定是其父目录。如果程序能...
库是在window平台下编译,64位,共有debug和release两个版本,同时提供完整头文件。 还写了一个使用log4cxx库文件的示例程序,使用Qt编写,亲测可用,示例程序内含配置文件示例。 如果您是Qt程序源,使用该库时可...
整理了CRT运行库、MFC运行库, 有DEBUG、RELEASE两个版本。 可解决未安装VS2008开发环境或VS2008的运行库,启动VS2008编译的程序出错问题。
狂龙Vc自制程序版本信息编辑器v2.0是继v1.0版之后推出的升级版。重点对程序内部代码进行全面优化并对用户在win7、win10中使用编辑器出现的Bug进行修复,新增...4、针对Release发布版本与Debug调试版本进行内部优化;