關於Debug和Release之本質區別的討論

一、Debug和Release編譯方式的本質區別 

         Debug通常稱為除錯版本，它包含除錯資訊，並且不作任何優化，便於程式師除錯程式。Release稱為發佈版本，它往往是進行了各種優化，使得程式在代碼大小和運行速度上都是最優的，以便用戶很好地使用。

         Debug和Release的真正秘密，在於一組編譯選項。下面列出了分別針對二者的選項（當然除此之外還有其他一些，如/Fd、/Fo，但區別並不重要，通常他們也不會引起Release版錯誤，在此不討論）
Debug版本：

Release 版本：

         實際上，Debug和Release並沒有本質的界限，他們只是一組編譯選項的集合，編譯器只是按照預定的選項行動。事實上，我們甚至可以修改這些選項，從而得到優化過的除錯版本或是帶跟蹤語句的發佈版本。

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

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

• Runtime Library

         連結哪種運行時刻函數庫通常只對程式的性能產生影響。除錯版本的Runtime Library包含了除錯資訊，並採用了一些保護機制以幫助發現錯誤，因此性能不如發佈版本。編譯器提供的Runtime Library通常很穩定，不會造成Release版錯誤；倒是由於Debug的Runtime Library加強了對錯誤的檢測，如heap記憶體分配，有時會出現Debug有錯但Release正常的現象。應當指出的是，如果Debug有錯，即使Release正常，程式肯定是有Bug的，只不過可能是Release版的某次運行沒有表現出來而已。

• 優化

         這是造成錯誤的主要原因，因為關閉優化時根源程式基本上是直接翻譯的，而打開優化後編譯器會作出一系列假設。這類錯誤主要有以下幾種：

         (1) 幀指標(Frame Pointer)省略(簡稱FPO)：在函數調用過程中，所有調用資訊(返回位址、參數)以及自動變數都是放在stack中的。若函數的聲明與實現不同(參數、返回值、調用方式)，就會產生錯誤，但Debug方式下，heap的訪問通過EBP寄存器保存的位址實現，如果沒有發生陣列越界之類的錯誤(或是越界“不多”)，函數通常能正常執行；Release方式下，優化會省略EBP heap基址指標，這樣通過一個全域指標訪問heap就會造成返回位址錯誤是程式崩潰。C++的強類型特性能檢查出大多數這樣的錯誤，但如果用了強制類型轉換，就不行了。你可以在Release版本中強制加入/Oy-編譯選項來關掉幀指標省略，以確定是否此類錯誤。

         (2) volatile型變數：volatile告訴編譯器該變數可能被程式之外的未知方式修改（如系統、其他進程和線程）。優化程式為了使程式性能提高，常把一些變數放在寄存器中（類似於register關鍵字），而其他進程只能對該變數所在的記憶體進行修改，而寄存器中的值沒變。如果你的程式是多線程的，或者你發現某個變數的值與預期的不符而你確信已正確的設置了，則很可能遇到這樣的問題。這種錯誤有時會表現為程式在最快優化出錯而最小優化正常。把你認為可疑的變數加上volatile試試。

         (3) 變數優化：優化程式會根據變數的使用情況優化變數。例如，函數中有一個未被使用的變數，在 Debug版中它有可能掩蓋一個陣列越界，而在Release版中，這個變數很可能被優化掉，此時陣列越界會破壞棧中有用的資料。當然，實際的情況會比這複雜得多。與此有關的錯誤有非法訪問，包括陣列越界、指標錯誤等。

• _DEBUG與 NDEBUG

         當定義了_DEBUG時，assert()函數會被編譯，而NDEBUG時不被編譯。唯一的例外是VERIFY()。事實上，這些巨集都是調用了assert()函數，只不過附加了一些與庫有關的除錯代碼。如果你在這些巨集中加入了任何程式碼，而不只是布林運算式（例如賦值、能改變變數值的函數調用等），那麼Release版都不會執行這些操作，從而造成錯誤。初學者很容易犯這類錯誤，查找的方法也很簡單，因為這些巨集都已在上面列出，只要利用VC++的Find in Files功能在工程所有檔中找到用這些巨集的地方再一一檢查即可。另外，有些高手可能還會加入ifdef _DEBUG之類的條件編譯，也要注意一下。
    順便值得一提的是VERIFY()巨集，這個巨集允許你將程式碼放在布林運算式裏。這個巨集通常用來檢查Windows API的返回值。有些人可能為這個原因而濫用VERIFY()，事實上這是危險的，因為VERIFY()違反了斷言的思想，不能使程式碼和除錯代碼完全分離，最終可能會帶來很多麻煩。因此，專家們建議儘量少用這個巨集。

• /GZ選項

         這個選項會做以下這些事：

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

         (3)函數返回前檢查stack指標，確認未被修改。（防止越界訪問和原形不匹配，與第二項合在一起可大致模擬幀指標省略FPO）

         通常/GZ選項會造成Debug版出錯而Release版正常的現象，因為Release版中未初始化的變數是隨機的，這有可能使指標指向一個有效位址而掩蓋了非法訪問。

• /Gm和/GF

         /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...中，選中Settingsfor”Win32 Release“，選中C/C++標籤，Category選General，DebugInfo選Program Database。在Link標籤Project options最後加上”/OPT:REF”(引號不要輸入)。這樣除錯器就能使用pdb檔中的除錯符號。但除錯時你會發現中斷點很難設置，變數也很難找到，因為這些都被優化過了。不過令人慶幸的是，Call Stack視窗仍然工作正常，即使幀指標被優化，heap資訊（特別是返回位址）仍然能找到。這對定位錯誤很有幫助。