青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

平凡的天才

目的是為人類造福
posts - 20, comments - 41, trackbacks - 0, articles - 6
  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

關(guān)于Debug和Release之本質(zhì)區(qū)別??????????????????????????????????????

經(jīng)常在 CSDN 上看見有人問 Debug 運行正常但 Release 失敗的問題。以往的討論往往是
經(jīng)驗性的,并沒有指出會這樣的真正原因是什么,要想找出真正的原因通常要憑運氣。最
近我看了一些這方面的書,又參考了 CSDN 上的一些帖子,然后深入研究了一下關(guān)于二者
的不同。以下是我的一些體會,拿來與大家共享。
--------------------------------------
本文主要包含如下內(nèi)容:
1. Debug 和 Release 編譯方式的本質(zhì)區(qū)別
2. 哪些情況下 Release 版會出錯
2. 怎樣“調(diào)試” Release 版的程序
--------------------------------------

??????????? 關(guān)于Debug和Release之本質(zhì)區(qū)別的討論

一、Debug 和 Release 編譯方式的本質(zhì)區(qū)別

??? Debug 通常稱為調(diào)試版本,它包含調(diào)試信息,并且不作任何優(yōu)化,便于程序員調(diào)試程
序。Release 稱為發(fā)布版本,它往往是進行了各種優(yōu)化,使得程序在代碼大小和運行速度
上都是最優(yōu)的,以便用戶很好地使用。
??? Debug 和 Release 的真正秘密,在于一組編譯選項。下面列出了分別針對二者的選項
(當(dāng)然除此之外還有其他一些,如/Fd /Fo,但區(qū)別并不重要,通常他們也不會引起 Rele
ase 版錯誤,在此不討論)

Debug 版本:
?/MDd /MLd 或 /MTd?? 使用 Debug runtime library(調(diào)試版本的運行時刻函數(shù)庫)
?/Od???????????????? 關(guān)閉優(yōu)化開關(guān)
?/D "_DEBUG"???????? 相當(dāng)于 #define _DEBUG,打開編譯調(diào)試代碼開關(guān)(主要針對
???????????????????? assert函數(shù))
?/ZI???????????????? 創(chuàng)建 Edit and continue(編輯繼續(xù))數(shù)據(jù)庫,這樣在調(diào)試過
???????????????????? 程中如果修改了源代碼不需重新編譯
?/GZ???????????????? 可以幫助捕獲內(nèi)存錯誤
?/Gm???????????????? 打開最小化重鏈接開關(guān),減少鏈接時間

Release 版本:
?/MD /ML 或 /MT????? 使用發(fā)布版本的運行時刻函數(shù)庫
?/O1 或 /O2????????? 優(yōu)化開關(guān),使程序最小或最快
?/D "NDEBUG"???????? 關(guān)閉條件編譯調(diào)試代碼開關(guān)(即不編譯assert函數(shù))
?/GF???????????????? 合并重復(fù)的字符串,并將字符串常量放到只讀內(nèi)存,防止
???????????????????? 被修改

??? 實際上,Debug 和 Release 并沒有本質(zhì)的界限,他們只是一組編譯選項的集合,編譯
器只是按照預(yù)定的選項行動。事實上,我們甚至可以修改這些選項,從而得到優(yōu)化過的調(diào)
試版本或是帶跟蹤語句的發(fā)布版本。

二、哪些情況下 Release 版會出錯

??? 有了上面的介紹,我們再來逐個對照這些選項看看 Release 版錯誤是怎樣產(chǎn)生的

?1. Runtime Library:鏈接哪種運行時刻函數(shù)庫通常只對程序的性能產(chǎn)生影響。調(diào)試版本
的 Runtime Library 包含了調(diào)試信息,并采用了一些保護機制以幫助發(fā)現(xiàn)錯誤,因此性能
不如發(fā)布版本。編譯器提供的 Runtime Library 通常很穩(wěn)定,不會造成 Release 版錯誤
;倒是由于 Debug 的 Runtime Library 加強了對錯誤的檢測,如堆內(nèi)存分配,有時會出
現(xiàn) Debug 有錯但 Release 正常的現(xiàn)象。應(yīng)當(dāng)指出的是,如果Debug有錯,即使 Release
正常,程序肯定是有 Bug 的,只不過可能是 Release版的某次運行沒有表現(xiàn)出來而已。


?2. 優(yōu)化:這是造成錯誤的主要原因,因為關(guān)閉優(yōu)化時源程序基本上是直接翻譯的,而打
開優(yōu)化后編譯器會作出一系列假設(shè)。這類錯誤主要有以下幾種:

??? (1) 幀指針(Frame Pointer)省略(簡稱 FPO ):在函數(shù)調(diào)用過程中,所有調(diào)用信息
(返回地址、參數(shù))以及自動變量都是放在棧中的。若函數(shù)的聲明與實現(xiàn)不同(參數(shù)、返
回值、調(diào)用方式),就會產(chǎn)生錯誤————但 Debug 方式下,棧的訪問通過 EBP 寄存器
保存的地址實現(xiàn),如果沒有發(fā)生數(shù)組越界之類的錯誤(或是越界“不多”),函數(shù)通常能
正常執(zhí)行;Release 方式下,優(yōu)化會省略 EBP 棧基址指針,這樣通過一個全局指針訪問棧
就會造成返回地址錯誤是程序崩潰。C++ 的強類型特性能檢查出大多數(shù)這樣的錯誤,但如
果用了強制類型轉(zhuǎn)換,就不行了。你可以在 Release 版本中強制加入 /Oy- 編譯選項來關(guān)
掉幀指針省略,以確定是否此類錯誤。此類錯誤通常有:

???? ● MFC 消息響應(yīng)函數(shù)書寫錯誤。正確的應(yīng)為
????? afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam);
????? ON_MESSAGE 宏包含強制類型轉(zhuǎn)換。防止這種錯誤的方法之一是重定義 ON_MESSAGE
?宏,把下列代碼加到 stdafx.h 中(在#include "afxwin.h"之后),函數(shù)原形錯誤時編譯
會報錯
????? #undef ON_MESSAGE
????? #define ON_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 告訴編譯器該變量可能被程序之外的未知方式修改
(如系統(tǒng)、其他進程和線程)。優(yōu)化程序為了使程序性能提高,常把一些變量放在寄存器
中(類似于 register 關(guān)鍵字),而其他進程只能對該變量所在的內(nèi)存進行修改,而寄存
器中的值沒變。如果你的程序是多線程的,或者你發(fā)現(xiàn)某個變量的值與預(yù)期的不符而你確
信已正確的設(shè)置了,則很可能遇到這樣的問題。這種錯誤有時會表現(xiàn)為程序在最快優(yōu)化出
錯而最小優(yōu)化正常。把你認(rèn)為可疑的變量加上 volatile 試試。

??? (3) 變量優(yōu)化:優(yōu)化程序會根據(jù)變量的使用情況優(yōu)化變量。例如,函數(shù)中有一個未被
使用的變量,在 Debug 版中它有可能掩蓋一個數(shù)組越界,而在 Release 版中,這個變量
很可能被優(yōu)化調(diào),此時數(shù)組越界會破壞棧中有用的數(shù)據(jù)。當(dāng)然,實際的情況會比這復(fù)雜得
多。與此有關(guān)的錯誤有:
???? ● 非法訪問,包括數(shù)組越界、指針錯誤等。例如
???????? void fn(void)
???????? {
?????????? int i;
?????????? i = 1;
?????????? int a[4];
?????????? {
???????????? int j;
???????????? j = 1;
?????????? }
?????????? a[-1] = 1;//當(dāng)然錯誤不會這么明顯,例如下標(biāo)是變量
?????????? a[4] = 1;
???????? }
?????? j 雖然在數(shù)組越界時已出了作用域,但其空間并未收回,因而 i 和 j 就會掩蓋越
界。而 Release 版由于 i、j 并未其很大作用可能會被優(yōu)化掉,從而使棧被破壞。

3. _DEBUG 與 NDEBUG :當(dāng)定義了 _DEBUG 時,assert() 函數(shù)會被編譯,而 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 控制。

??? 所有這些斷言都只在 Debug版中才被編譯,而在 Release 版中被忽略。唯一的例外是
?VERIFY() 。事實上,這些宏都是調(diào)用了 assert() 函數(shù),只不過附加了一些與庫有關(guān)的
調(diào)試代碼。如果你在這些宏中加入了任何程序代碼,而不只是布爾表達式(例如賦值、能
改變變量值的函數(shù)調(diào)用 等),那么 Release 版都不會執(zhí)行這些操作,從而造成錯誤。初
學(xué)者很容易犯這類錯誤,查找的方法也很簡單,因為這些宏都已在上面列出,只要利用 V
C++ 的 Find in Files 功能在工程所有文件中找到用這些宏的地方再一一檢查即可。另外
,有些高手可能還會加入 #ifdef _DEBUG 之類的條件編譯,也要注意一下。
??? 順便值得一提的是 VERIFY() 宏,這個宏允許你將程序代碼放在布爾表達式里。這個
宏通常用來檢查 Windows API 的返回值。有些人可能為這個原因而濫用 VERIFY() ,事實
上這是危險的,因為 VERIFY() 違反了斷言的思想,不能使程序代碼和調(diào)試代碼完全分離
,最終可能會帶來很多麻煩。因此,專家們建議盡量少用這個宏。

4. /GZ 選項:這個選項會做以下這些事

??? (1) 初始化內(nèi)存和變量。包括用 0xCC 初始化所有自動變量,0xCD ( Cleared Data
) 初始化堆中分配的內(nèi)存(即動態(tài)分配的內(nèi)存,例如 new ),0xDD ( Dead Data ) 填充
已被釋放的堆內(nèi)存(例如 delete ),0xFD( deFencde Data ) 初始化受保護的內(nèi)存(de
bug 版在動態(tài)分配內(nèi)存的前后加入保護內(nèi)存以防止越界訪問),其中括號中的詞是微軟建
議的助記詞。這樣做的好處是這些值都很大,作為指針是不可能的(而且 32 位系統(tǒng)中指
針很少是奇數(shù)值,在有些系統(tǒng)中奇數(shù)的指針會產(chǎn)生運行時錯誤),作為數(shù)值也很少遇到,
而且這些值也很容易辨認(rèn),因此這很有利于在 Debug 版中發(fā)現(xiàn) Release 版才會遇到的錯
誤。要特別注意的是,很多人認(rèn)為編譯器會用 0 來初始化變量,這是錯誤的(而且這樣很
不利于查找錯誤)。
??? (2) 通過函數(shù)指針調(diào)用函數(shù)時,會通過檢查棧指針驗證函數(shù)調(diào)用的匹配性。(防止原
形不匹配)
??? (3) 函數(shù)返回前檢查棧指針,確認(rèn)未被修改。(防止越界訪問和原形不匹配,與第二
項合在一起可大致模擬幀指針省略 FPO )

??? 通常 /GZ 選項會造成 Debug 版出錯而 Release 版正常的現(xiàn)象,因為 Release 版中
未初始化的變量是隨機的,這有可能使指針指向一個有效地址而掩蓋了非法訪問。

除此之外,/Gm /GF 等選項造成錯誤的情況比較少,而且他們的效果顯而易見,比較容易
發(fā)現(xiàn)。

三、怎樣“調(diào)試” Release 版的程序

??? 遇到 Debug 成功但 Release 失敗,顯然是一件很沮喪的事,而且往往無從下手。如
果你看了以上的分析,結(jié)合錯誤的具體表現(xiàn),很快找出了錯誤,固然很好。但如果一時找
不出,以下給出了一些在這種情況下的策略。

??? 1. 前面已經(jīng)提過,Debug 和 Release 只是一組編譯選項的差別,實際上并沒有什么
定義能區(qū)分二者。我們可以修改 Release 版的編譯選項來縮小錯誤范圍。如上所述,可以
把 Release 的選項逐個改為與之相對的 Debug 選項,如 /MD 改為 /MDd、/O1 改為 /Od
,或運行時間優(yōu)化改為程序大小優(yōu)化。注意,一次只改一個選項,看改哪個選項時錯誤消
失,再對應(yīng)該選項相關(guān)的錯誤,針對性地查找。這些選項在 Project\Settings... 中都可
以直接通過列表選取,通常不要手動修改。由于以上的分析已相當(dāng)全面,這個方法是最有
效的。

??? 2. 在編程過程中就要時常注意測試 Release 版本,以免最后代碼太多,時間又很緊

??? 3. 在 Debug 版中使用 /W4 警告級別,這樣可以從編譯器獲得最大限度的錯誤信息,
比如 if( i =0 )就會引起 /W4 警告。不要忽略這些警告,通常這是你程序中的 Bug 引起
的。但有時 /W4 會帶來很多冗余信息,如 未使用的函數(shù)參數(shù) 警告,而很多消息處理函數(shù)
都會忽略某些參數(shù)。我們可以用
????? #progma warning(disable: 4702) //禁止
????? //...
????? #progma warning(default: 4702) //重新允許
來暫時禁止某個警告,或使用
????? #progma warning(push, 3) //設(shè)置警告級別為 /W3
????? //...
????? #progma warning(pop) //重設(shè)為 /W4
來暫時改變警告級別,有時你可以只在認(rèn)為可疑的那一部分代碼使用 /W4。

??? 4.你也可以像 Debug 一樣調(diào)試你的 Release 版,只要加入調(diào)試符號。在 Project/S
ettings... 中,選中 Settings for "Win32 Release",選中 C/C++ 標(biāo)簽,Category 選
?General,Debug Info 選 Program Database。再在 Link 標(biāo)簽 Project options? 最后
加上 "/OPT:REF" (引號不要輸)。這樣調(diào)試器就能使用 pdb 文件中的調(diào)試符號。但調(diào)試時
你會發(fā)現(xiàn)斷點很難設(shè)置,變量也很難找到——這些都被優(yōu)化過了。不過令人慶幸的是,Ca
ll Stack 窗口仍然工作正常,即使幀指針被優(yōu)化,棧信息(特別是返回地址)仍然能找到
。這對定位錯誤很有幫助。

Feedback

# re: 關(guān)于Debug和Release之本質(zhì)區(qū)別  回復(fù)  更多評論   

2013-07-25 11:05 by 飛飛龍
學(xué)習(xí)了

只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美一区二区视频在线观看| aⅴ色国产欧美| 亚洲欧美卡通另类91av| 日韩视频欧美视频| 午夜在线不卡| 亚洲欧洲一级| 亚洲国产一区二区三区在线播| 国产精品免费看片| 很黄很黄激情成人| 亚洲一二三区精品| 香蕉久久夜色精品国产| 免费亚洲电影在线| 国产精品视频精品| 亚洲毛片av| 久久精品国产亚洲一区二区三区| 欧美日韩在线影院| 亚洲精品欧美| 亚洲人成毛片在线播放| 免费成人黄色片| 狠狠入ady亚洲精品| 亚洲一区二区动漫| 欧美系列一区| 性8sex亚洲区入口| 国产精品免费看久久久香蕉| 欧美高清在线一区二区| 久久精品99国产精品日本| 国产一区二区精品久久| 亚洲欧美中文在线视频| 亚洲伊人网站| 国产精品av一区二区| 亚洲高清久久| 老司机免费视频一区二区三区| 狠狠色伊人亚洲综合成人| 午夜亚洲影视| 日韩视频不卡| 欧美日韩在线视频一区二区| 亚洲精品一区二区三区蜜桃久| 欧美日韩一区二区视频在线观看| 香港成人在线视频| 国产一区二区高清| 免费一级欧美片在线观看| 欧美激情一区在线| 国产免费亚洲高清| 亚洲人成7777| 久久久av水蜜桃| 欧美久久婷婷综合色| 欧美 日韩 国产精品免费观看| 欧美视频一区二| 久久久欧美精品| 久久天天躁夜夜躁狠狠躁2022| 欧美护士18xxxxhd| 久久蜜臀精品av| 国产一区二区三区四区三区四| 欧美成人a∨高清免费观看| 久久超碰97中文字幕| 欧美色网一区二区| 免费国产一区二区| 久久麻豆一区二区| 久久视频在线视频| 欧美一级久久| 亚洲女性裸体视频| 欧美一级片久久久久久久| 欧美另类高清视频在线| 亚洲丰满在线| 欧美黄色大片网站| 亚洲观看高清完整版在线观看| 欧美风情在线观看| 亚洲国产欧美在线人成| 亚洲一区自拍| 日韩一区二区精品视频| 久久国产婷婷国产香蕉| 亚洲午夜精品福利| 亚洲专区一区| 欧美一区二区三区在线看 | 亚洲人被黑人高潮完整版| 欧美综合国产| 亚洲国产精品成人综合| 亚洲人成人一区二区在线观看| 国产私拍一区| 久久久精品999| 久久久久一区二区三区| 欧美1级日本1级| 欧美激情在线免费观看| 亚洲一区一卡| 欧美一区二区三区在线免费观看 | 最新国产成人av网站网址麻豆 | 国产麻豆精品在线观看| 尤物网精品视频| 欧美三级韩国三级日本三斤| 国产日韩欧美精品综合| 99国产精品自拍| 免费毛片一区二区三区久久久| 亚洲综合色自拍一区| 欧美高清在线| 欧美在线免费播放| 国产视频精品免费播放| 亚洲午夜精品网| 亚洲乱码国产乱码精品精天堂| 久久久久久久91| 国产一区91| 麻豆久久婷婷| 久久久久综合| 香蕉av777xxx色综合一区| 国产精品二区二区三区| 久久久久久夜| 久久综合九色综合久99| 一区二区三区自拍| 亚洲美女在线观看| 欧美激情一区在线观看| 欧美成人精品| 妖精成人www高清在线观看| 亚洲日本成人在线观看| 日韩一二三区视频| 欧美在线视频日韩| 亚洲欧美中文另类| 最近中文字幕日韩精品| 免费在线观看一区二区| 久久精品99国产精品酒店日本| 亚洲国产国产亚洲一二三| 一区二区在线观看视频在线观看 | 亚洲一区二区少妇| 欧美激情一区二区三区高清视频| 亚洲四色影视在线观看| 亚洲电影激情视频网站| 国产主播一区二区| 亚洲欧美中文另类| 欧美精品一区三区在线观看| 欧美一区二区视频在线| 欧美日韩一区在线观看| 久久综合给合久久狠狠狠97色69| 欧美日韩在线影院| 欧美激情中文字幕乱码免费| 国产一区二区三区日韩| 亚洲综合国产| 国产日韩欧美综合在线| 一区二区三区高清不卡| 国产精品国产三级国产专播精品人 | 久久一综合视频| 久久美女艺术照精彩视频福利播放| 国产精品视频网址| 亚洲一区综合| 久久精品国产视频| 国产亚洲精品一区二区| 久久久成人精品| 久久亚洲精品一区| 亚洲精品男同| 国产精品午夜视频| 一二三四社区欧美黄| 欧美色精品天天在线观看视频| 一本不卡影院| 久久精品五月婷婷| 一本久久a久久精品亚洲| 欧美日产一区二区三区在线观看| 亚洲国产午夜| 欧美麻豆久久久久久中文| 99视频有精品| 噜噜噜躁狠狠躁狠狠精品视频| 在线观看亚洲视频| 亚洲大胆av| 国产精品女主播| 欧美亚洲一区二区在线观看| 免费亚洲一区二区| 亚洲欧美韩国| 亚洲国产一区二区在线| 国产视频在线一区二区| 欧美日韩国产黄| 久久久久久伊人| 亚洲性图久久| 亚洲精品专区| 亚洲国产成人高清精品| 校园激情久久| 一区二区久久久久久| 欧美日韩亚洲一区二区三区四区| 久久精品女人天堂| 久久爱另类一区二区小说| 亚洲视频专区在线| 一区二区三区欧美在线| 99国产精品| 亚洲色图在线视频| 亚洲在线视频| 欧美一区二区三区四区在线 | 亚洲一区免费网站| 亚洲图片在线观看| 欧美一区二区三区电影在线观看| 欧美一级视频| 欧美午夜视频一区二区| 在线高清一区| 久久大综合网| 日韩一区二区精品葵司在线| 久久人人爽国产| 国产精品制服诱惑| 亚洲视频第一页| 亚洲大胆在线| 久久婷婷麻豆| 伊人久久久大香线蕉综合直播| 欧美aaa级| 黄色小说综合网站| 性欧美xxxx视频在线观看| 久久国产日本精品| 亚洲国产欧美一区|