維尼的蜂巢

RealTime??!! It’s amazing!!!!

release和debug的不同 四月 19, 2006

Filed under: VC++/C++/C — kevinlin @ 12:20 上午

有時候常常會遇到Debug可以跑 但是Release反而不能跑了 為什麼呢?
這實在很奧妙 所以要好好了解一下這兩個的差異
還有 所以我們常常需要在一個階段就Release編譯一次 這樣才不會最後手足無措 

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 合併重複的字串, 並將字串常數放到ROM中, 防止被修改

事實上呢 Debug 和 Release 並沒有本質的界限 他們只是一組編譯選項的集合 編譯器只是按照預定的選項行動。
事實上 我們甚至可以修改這些選項 從而得到最佳化過的測試版本或是帶跟蹤語法的正式版本。

哪些情況下 Release 版會出錯

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

1、Runtime Library:鏈接哪種執行時的函式庫通常只對程式的性能產生影響。測試版本的 Runtime Library 包含了測試用的訊息,並採用了一些保護機制以幫助發現錯誤,所以性能上較不如Release的版本。編譯器提供的 Runtime Library 通常很穩定,不會造成 Release 版本錯誤;倒是由於 Debug 的 Runtime Library 加強了對錯誤的檢測,如Heap的記憶體分配,有時會出現 Debug 有錯但 Release 正常的現象。這裡要注意的是,如果 Debug 有錯,即使 Release 正常,程式保證是有 Bug 的,只不過可能是 Release 版的某次執行沒有表現出來而已。

2、最佳化:這是造成錯誤的主要原因,因為關閉最佳化時原始程式基本上是直接翻譯的,而打開最佳化後編譯器會作出一系列假設。這類錯誤主要有以下幾種:

1. Frame Pointer的省略(簡稱FPO):在函式的呼叫過程中,所有呼叫的訊息(回傳位址、參數)以及自動變數都是放在堆疊中的。如果函式的宣告跟實作不同(參數、回傳值、呼叫方式),就會產生錯誤,但 Debug 方式下,堆疊的存取透過 EBP 暫存器儲存的位址來實現,如果沒有發生數組越界之類的錯誤(或是越界「不多」),函式通常能正常執行;Release 方式下,最佳化會省略 EBP 堆疊基本位址的指標,這樣通過一個全域指標存取堆疊就會造成回傳位址錯誤導致整個程式崩潰。

C++ 的強類型特性能檢查出大多數這樣的錯誤,但如果用了強制類型轉換,就不行了。你可以在 Release 版本中強制加入/Oy-編譯選項來關掉FPO,以確定是否此類錯誤。此類錯誤通常有:MFC 訊息響應函式不小心寫錯。正確的應為:
afx_msg LRESULT OnMessageOwn  WPARAM wparam, LPARAM lparam);
¼br /> ON_MESSAGE 巨集包含強制類型轉換。防止這種錯誤的方法之一是重新定義 ON_MESSAGE巨集,把下列程式碼加到 stdafx.h 中(在#include “afxwin.h"之後),函式原形錯誤時編譯會報錯。
#undef ON_MESSAGE
#define ON_MESSAGE(message, memberFxn) \
{
message, 0, 0, 0, AfxSig_lwl, \
(AFX_PMSG)(AFX_PMSGW)
(static_cast (&memberFxn)
},

2. volatile 型的變數:volatile告訴編譯器該變數可能被程式之外的未知方式修改(如系統、其他process或thread)。最佳化程式為了使程式性能提高,常把一些變數放在暫存器中(類似於 register 關鍵字),而其他process只能對該變量所在的記憶體進行修改,而暫存器中的值沒變。

如果你的程式是多執行緒的,或者你發現某個變數的值與預期的不符而你確定已經正確的設置了,那就很可能遇到這樣的問題。這種錯誤有時會表現為程式在最快的最佳化時出錯而最小的最佳化時正常。把你認為可疑的變數加上 volatile 試試。

3. 變數最佳化:最佳化程式會根據變數的使用情況最佳化變數。例如,函式中有一個未被使用的變數,在 Debug 版中它有可能掩蓋一個數組越界,而在 Release 版中,這個變數很可能被最佳化掉,此時數組越界會破壞堆疊中有用的資料。當然,實際的情況會比這複雜得多。與此有關的錯誤有非法存取,包括數組越界、指針錯誤等。例如:
void fn(void)
{
  int i;
  i = 1;
  int a[4];
  {
    int j;
    j = 1;
  }
  a[-1] = 1;
  //當然錯誤不會這麼明顯,例如下標是變數
  a[4] = 1;
}

 

j 雖然在數組越界時已出了作用域,但其空間並未收回,因此 i 和 j 就會掩蓋越界。而 Release 版由於 i、j 並未其很大作用可能會被最佳化掉,進而使堆疊被破壞。

3. DEBUG 與 NDEBUG :當定義了 _DEBUG 時,assert() 函式會被編譯,而 NDEBUG 時不被編譯。此外,TRACE() 巨集的編譯也受 _DEBUG 控制。

所有這些ASSERT都只在 Debug版中才被編譯,而在 Release 版中被忽略。唯一的例外是 VERIFY()。事實上,這些巨集都是呼叫assert()函數,只不過附加了一些與library有關的測試程式碼。如果你在這些巨集中加入了任何程式碼,而不只是bool(例如賦值、能改變變數值的函式呼叫等),那麼Release版都不會執行這些操作,從而造成錯誤。初學者很容易犯這類錯誤,查找的方法也很簡單,因為這些巨集都已在上面列出,只要利用 VC++ 的 Find in Files 功能在方案的所有文件中找到用這些巨集的地方再一一檢查即可。另外,有些高手可能還會加入 #ifdef _DEBUG 之類的條件編譯,也要注意一下。

順便值得一提的是VERIFY()巨集,這個巨集允許你將程式碼放在bool表達式裡。這個巨集通常用來檢查 Windows API的返回值。有些人可能為這個原因而濫用VERIFY(),事實上這是危險的,因為VERIFY()違反了ASSERT的思想,不能使程式碼和測試程式碼完全分離,最終可能會帶來很多麻煩。因此,專家們通常都建議盡量少用這個巨集。

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

1. 初始化記憶體和變數。包括用 0xCC 初始化所有自動變數,0xCD ( Cleared Data ) 初始化Heap中分配的記憶體(即動態分配的記憶體,例如 new ),0xDD ( Dead Data ) 填充已被釋放的Heap記憶體(例如 delete ),0xFD( deFencde Data ) 初始化受保護的記憶體(debug 版在動態分配記憶體的前後加入保護記憶體以防止越界存取),其中括號中的詞是微軟建議的助記詞。這樣做的好處是這些值都很大,作為指標是不可能的(而且 32 位系統中指標很少是奇數值,在有些系統中奇數的指標會產生運行時錯誤),作為數值也很少遇到,而且這些值也很容易辨認,因此這很有利於在 Debug 版中發現 Release 版才會遇到的錯誤。要特別注意的是,很多人認為編譯器會用0來初始化變數,這是錯誤的(而且這樣很不利於尋找錯誤)。

2. 通過函式指標呼叫函數時,會通過檢查堆疊指標驗證函式呼叫的匹配性。(防止原形不匹配)

3. 函式返回前檢查堆疊指標,確認未被修改。(防止越界訪問和原形不匹配,與第二項合在一起可大致模擬 FPO )通常 /GZ 選項會造成 Debug 版出錯而 Release 版正常的現象,因為 Release 版中未初始化的變量是隨機的,這有可能使指針指向一個有效地址而掩蓋了非法訪問。除此之外,/Gm/GF等選項造成錯誤的情況比較少,而且他們的效果顯而易見,比較容易發現。

怎樣「測試」 Release 版的程序

遇到Debug成功但Release失敗,顯然是一件很沮喪的事,而且往往無從下手,然後你就氣到吐血,把程式全部刪光。如果你看了上面的分析,結合錯誤的具體表現,很快找出了錯誤,固然很好。但如果一時找不出,以下給出了一些在這種情況下的方法。

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

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

3. 在 Debug 版中使用 /W4 警告級別,這樣可以從編譯器獲得最大限度的錯誤信息,比如 if( i =0 )就會引起 /W4 警告。不要忽略這些警告,通常這是你程序中的 Bug 引起的。但有時 /W4 會帶來很多冗余信息,如 未使用的函數參數 警告,而很多消息處理函數都會忽略某些參數。我們可以用:

#progma warning(disable: 4702)
//禁止
//…
#progma warning(default: 4702)
//重新允許來暫時禁止某個警告,或使用
#progma warning(push, 3)
//設置警告級別為 /W3
//…
#progma warning(pop)
//重設為 /W4

 來暫時改變警告級別,有時你可以只在認為可疑的那一部分程式碼使用 /W4。

4. 你也可以像Debug一樣測試你的Release版,只要加入測試符號。在Project/Settings… 中,選中 Settings for “Win32 Release",選中 C/C++ 標籤,Category 選 General,Debug Info 選 Program Database。再在 Link 標籤 Project options 最後加上 “/OPT:REF" (引號不要輸入)。這樣測試器就能使用 pdb 文件中的測試符號。

但測試時你會發現斷點很難設置,變數也很難找到??這些都被最佳化過了。不過令人慶幸的是,Call Stack窗口仍然工作正常,即使Frame Point被最佳化,但堆疊訊息(特別是返回地址)仍然能找到。這對定位錯誤很有幫助。

 

One Response to “release和debug的不同”


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s