关于Debug和Release的讨论

 

 

1、摘自：http://blog.youkuaiyun.com/skyhsu/archive/2007/06/06/1641043.aspx

关于Debug和Release之本质区别的讨论本文主要包含如下内容：
1. Debug 和 Release 编译方式的本质区别
2. 哪些情况下 Release 版会出错
2. 怎样“调试” Release 版的程序

一、Debug 和 Release 编译方式的本质区别
Debug 通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程
序。Release 称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度
上都是最优的，以便用户很好地使用。
Debug 和 Release 的真正秘密，在于一组编译选项。下面列出了分别针对二者的选项
（当然除此之外还有其他一些，如/Fd /Fo，但区别并不重要，通常他们也不会引起 Rele
ase 版错误，在此不讨论）
Debug 版本：
/MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)
/Od 关闭优化开关
/D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对
assert函数)
/ZI 创建 Edit and continue(编辑继续)数据库，这样在调试过
程中如果修改了源代码不需重新编译
/GZ 可以帮助捕获内存错误
/Gm 打开最小化重链接开关，减少链接时间

Release 版本：
/MD /ML 或 /MT 使用发布版本的运行时刻函数库
/O1 或 /O2 优化开关，使程序最小或最快
/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)
/GF 合并重复的字符串，并将字符串常量放到只读内存，防止
被修改
实际上，Debug 和 Release 并没有本质的界限，他们只是一组编译选项的集合，编译
器只是按照预定的选项行动。事实上，我们甚至可以修改这些选项，从而得到优化过的调
试版本或是带跟踪语句的发布版本。

二、哪些情况下 Release 版会出错

有了上面的介绍，我们再来逐个对照这些选项看看 Release 版错误是怎样产生的

1. Runtime Library：

2. 优化：这类错误主要有以下几种：

(1) 帧指针(Frame Pointer)省略（简称 FPO ）：在函数调用过程中，所有调用信息
（返回地址、参数）以及自动变量都是放在栈中的。若函数的声明与实现不同（参数、返
回值、调用方式），就会产生错误————但 Debug 方式下，栈的访问通过 EBP 寄存器
保存的地址实现，如果没有发生数组越界之类的错误（或是越界“不多”），函数通常能
正常执行；Release 方式下，优化会省略 EBP 栈基址指针，这样通过一个全局指针访问栈
就会造成返回地址错误是程序崩溃。C++ 的强类型特性能检查出大多数这样的错误，但如
果用了强制类型转换，就不行了。你可以在 Release 版本中强制加入 /Oy- 编译选项来关
掉帧指针省略，以确定是否此类错误。
(2) volatile 型变量：volatile 告诉编译器该变量可能被程序之外的未知方式修改
（如系统、其他进程和线程）。

(3) 变量优化：优化程序会根据变量的使用情况优化变量。例如，函数中有一个未被
使用的变量，在 Debug 版中它有可能掩盖一个数组越界，而在 Release 版中，这个变量
很可能被优化调，此时数组越界会破坏栈中有用的数据。当然，实际的情况会比这复杂得
多。与此有关的错误有：

3. _DEBUG 与 NDEBUG ：当定义了 _DEBUG 时，assert() 函数会被编译，而 NDEBUG 时不
被编译。除此之外，VC++中还有一系列断言宏。这包括：

ANSI C 断言 void assert(int expression );
C Runtime Lib 断言 _ASSERT( booleanExpression );
_ASSERTE( booleanExpression );
MFC 断言 ASSERT( booleanExpression );
VERIFY( booleanExpression );
ASSERT_VALID( pObject );
ASSERT_KINDOF( classname, pobject );
ATL 断言 ATLASSERT( booleanExpression );
此外，TRACE() 宏的编译也受 _DEBUG 控制。

4. /GZ 选项：这个选项会做以下这些事

(1) 初始化内存和变量。
(2) 通过函数指针调用函数时，会通过检查栈指针验证函数调用的匹配性。（防止原
形不匹配）
(3) 函数返回前检查栈指针，确认未被修改.

三、怎样“调试” Release 版的程序

1. 前面已经提过，Debug 和 Release 只是一组编译选项的差别，实际上并没有什么
定义能区分二者。我们可以修改 Release 版的编译选项来缩小错误范围。如上所述，可以
把 Release 的选项逐个改为与之相对的 Debug 选项，如 /MD 改为 /MDd、/O1 改为 /Od
，或运行时间优化改为程序大小优化。注意，一次只改一个选项，看改哪个选项时错误消
失，再对应该选项相关的错误，针对性地查找。这些选项在 Project/Settings... 中都可
以直接通过列表选取，通常不要手动修改。由于以上的分析已相当全面，这个方法是最有
效的。
2.你也可以像 Debug 一样调试你的 Release 版，只要加入调试符号。在 Project/S
ettings... 中，选中 Settings for "Win32 Release"，选中 C/C++ 标签，Category 选
General，Debug Info 选 Program Database。再在 Link 标签 Project options 最后
加上 "/OPT:REF" (引号不要输)。 

 2、摘自：http://dev.youkuaiyun.com/article/17/17068.shtm

VC下关于debug和release的不同的讨论 zx_sanjin(1.5kg), shanghai

create: 15:39 2002-12-20
modify: 13:56 2003-1-24

mail : zx_sanjin@163.com
qq : 923452

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

在使用VC开发软件的过程中，正当要享受那种兴奋的时候突然发现：release与debug运行结果不一致，甚至出错，而release又不方便调试，真的是当头一棒啊，可是疼归疼，问题总要解决，下面将讲述一下我的几点经验，看看是不是其中之一：

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

2. 自定义消息的消息参数。
 MFC为我们提供了很好的消息机制，更增加了自定义消息，好处我就不用多说了。这也存在debug跟release的问题吗？答案是肯定的。在自定义消息的函数体声明时，时常会看到这样的写法：afx_msg LRESULT OnMessageOwn(); Debug情况下一般不会有任何问题，而当你在Release下且多线程或进程间使用了消息传递时就会导致无效句柄之类的错误。导致这个错误直接原因是消息体的参数没有添加，即应该写成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); (注2)

3. release模式下不出错，但debug模式下报错。
 这种情况下大多也是因为代码书写不正确引起的，查看MFC的源码，可以发现好多ASSERT的语句(断言)，这个宏只是在debug模式下才有效，那么就清楚了，release版不报错是忽略了错误而不是没有错误，这可能存在很大的隐患，因为是Debug模式下，比较方便调试，好好的检查自己的代码，再此就不多说了。

4. ASSERT, VERIFY, TRACE..........调试宏
这种情况很容易解释。举个例子：请在VC下输入ASSERT然后选中按F12跳到宏定义的地方，这里你就能够发现Debug中ASSERT要执行AfxAssertFailedLine，而Release下的宏定义却为"#define ASSERT(f) ((void)0)"。所以注意在这些调试宏的语句不要用程序相关变量如i++写操作的语句。VERIFY是个例外，"#define VERIFY(f) ((void)(f))"，即执行，这里的作用就不多追究了，有兴趣可自己研究:)。

总结：
 Debug与Release不同的问题在刚开始编写代码时会经常发生，99%是因为你的代码书写错误而导致的，所以不要动不动就说系统问题或编译器问题，努力找找自己的原因才是根本。我从前就常常遇到这情况，经历过一次次的教训后我就开始注意了，现在我所写过的代码我已经好久没遇到这种问题了。下面是几个避免的方面，即使没有这种问题也应注意一下：

1. 注意变量的初始化，尤其是指针变量，数组变量的初始化(很大的情况下另作考虑了)。
2. 自定义消息及其他声明的标准写法
3. 使用调试宏时使用后最好注释掉
4. 尽量使用try - catch(...)
5. 尽量使用模块，不但表达清楚而且方便调试。

注1：
afc(afc) 网友提供：
 debug版初始化成0xcc是因为0xcc在x86下是一条int 3单步中断指令，这样程序如果跑飞了遇到0xcc就会停下来，这和单片机编程时一般将没用的代码空间填入jmp 0000语句是一样地

注2：
 不知大家有没有遇到过这种情况，具体原因我也不太清楚，是不是调用时按着默认的参数多分配了WPARAM+LPARAM的空间而破坏了应用程序的内存空间?还请高手来补充。

NightWolf 网友提供：我遇见过，好像是在函数调用的时候参数入栈的问题。因为MFC的消息使用宏写的，所以如果定义了OnMessage()的函数，编译能够通过，但是调用一次后，堆栈指针发生了偏移。然后就。。。