[windows] debug、release版本中的new,兩種模式區別

今天面試的時候,被問到了一個問題:

release版本下new了一個對象A, 將A傳入debug版本庫,發生錯誤?可能的原因是什麼呢?

debug模式下:

   1:  // debug模式下的new

   2:  #define new DEBUG_NEW

   3:   

   4:  //  DEBUG_NEW如下

   5:  #define DEBUG_NEW new(THIS_FILE, __LINE__)

   6:   

   7:  // 對於如上的new,編譯器會尋找如下定義的operator new

   8:  void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine)　{

   9:  　return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);

  10:  }

  11:   

  12:  // ::operator new的定義如下

  13:  void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine) {

  14:  　…

  15:  　pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine);  // 實際的記憶體配置

  16:  　if (pResult != NULL)

  17:  　　return pResult;

  18:  　…

  19:  }

  20: 

release模式下:  

   1:  // release模式下的new 

   2:  #define new DEBUG_NEW

   3:   

   4:  // DEBUG_NEW擴充如下

   5:  #define DEBUG_NEW new 

   6:   

   7:  // 調用的new版本為

   8:  void* __cdecl operator new(size_t nSize) {  

   9:    … 

  10:    pResult = malloc(nSize); //實際的記憶體配置

  11:   return pResult ; 

  12:  }

當然相應的delete操作也是不同的。很明顯，在debug模式與release模式下的new最終的動作是不同的，在debug模式下申請資料的時候會有一些追蹤資訊，檔案名稱，行數等等，也就是說在進行記憶體申請的時候實際分配的記憶體比申請的記憶體要大。如果在release模式下申請的對象,傳入debug版本的庫中,如果在debug版本的庫中調用了delete操作，可能會發生錯誤。

這個問題的回答其實很大程度上依賴於實際代碼經驗吧,其實回來想了想,自己一時還真說不清楚debug和release模式的區別,在這裡總結一下:

Debug版本包括調試資訊，所以要比Release版本大很多(可能大數百K至數M)。至於是否需要DLL支援，主要看你採用的編譯選項。如果是基於ATL的，則Debug和Release版本對DLL的要求差不多。如果採用的編譯選項為使用MFC動態庫，則需要MFC42D.DLL等庫支援，而Release版本需要MFC42.DLL支援。Release   Build不對原始碼進行調試，不考慮MFC的診斷宏，使用的是MFC   Release庫，編譯時間對應用程式的速度進行最佳化，而Debug   Build則正好相反，它允許對原始碼進行調試，可以定義和使用MFC的診斷宏，採用MFC   Debug庫，對速度沒有最佳化。反而加入了很多的調試資訊.

1. Debug和Release版本的本質區別 

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

在VC編譯器中, Debug版本和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	合并重複的字串，並將字串常量放到唯讀記憶體，防止被修改

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

2. 哪些情況下Release版會出錯

1). Runtime   Library 問題

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

2). 最佳化問題

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

    A : 幀指標省略(Frame Pointer,簡稱FPO),

         在函數調用過程中，所有調用資訊(返回地址、參數)以及自動變數都是放在棧中的。若函數的聲明與實現不同（參數、傳回值、調用方式），就會產生錯誤;

         但Debug方式下，棧的訪問通過EBP寄存器儲存的地址實現，如果沒有發生數組越界之類的錯誤(或是越界“不多”), 函數通常能正常執行;

         Relase方式下，最佳化會省略EBP棧基址指標，這樣通過一個全域指標訪問棧就會造成返回地址錯誤是程式崩潰。

         C++的強型別特效能檢查出大多數這樣的錯誤，但如果用了強制類型轉換，就不行了。你可以在Release版本中強制加入/Oy- 編譯選項來關掉幀指標省略，以確定是否此類錯誤。

         例如:

               MFC訊息響應函數書寫錯誤。正確的應為 

               afx_msg LRESULT OnMessageOwn(WPARAM wparam,LPARAM lparam);

               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<LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM,LPARAM)>(&memberFxn)},

    B:  volatile型變數

         volatile告訴編譯器該變數可能被程式之外的未知方式修改（如系統、其他進程和線程）。最佳化程式為了使程式效能提高，常把一些變數放在寄存器中(類似於register關鍵字)，而其他進

         程只能對該變數所在的記憶體進行修改，而寄存器中的值沒變。如果你的程式是多線程的，或者你發現某個變數的值與預期的不符而你確信已正確的設定了，則很可能遇到這樣的問題。這種

         錯誤有時會表現為程式在最快最佳化出錯而最小最佳化正常。把你認為可疑的變數加上volatile試試。

    C: 變數最佳化

        最佳化程式會根據變數的使用方式最佳化變數。

        例如, 函數中有一個未被使用的變數,在Debug版中它有可能掩蓋一個數組越界,而在Release版中,這個變數很可能被最佳化掉,此時數組越界會破壞棧中有用的資料。

        例如:

   1:  void   fn(void)   { 

   2:  int   i;   

   3:  i   =   1;   

   4:  int   a[4];   

   5:   

   6:  { 

   7:     int   j; 

   8:     j   =   1; 

   9:  }

  10:     

  11:  a[-1]   =   1;  //當然錯誤不會這麼明顯，例如下標是變數   

  12:  a[4]   =   1;   

  13:  } 

      j雖然在數組越界時已出了範圍，但其空間並未收回，因而i和j就會掩蓋越界。而Release版由於i，j並無很大作用可能會被最佳化掉，從而使棧被破壞。

3.  _DEBUG 與NDEBUG

當定義了_DEBUG時，assert()函數會被編譯，而NDEBUG時不被編譯。除此之外，VC++中還有一系列斷言宏。這包括:

ANSI C斷言	void   assert(int expression);
C Runtime Lib斷言	_ASSERTE(booleanExpression);_ASSERT(booleanExpression);
MFC斷言	ASSERT(booleanExpression); VERIFY(booleanExpression);  ASSERT_VALID(pObject);  ASSERT_KINDOF（classname,pobject);
ATL斷言	ATLASSERT(booleanExpression);

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

4.  變數初始化
     debug跟release在初始設定變數時所做的操作是不同的，debug 是將每個位元組位都賦成0xcc，而release的賦值近似於隨機(我想是直接從記憶體中分配的，沒有初始化過)。這樣就明確了，如果你的程式中的某個變數沒被初始化就被引用，就很有可能出現異常：用作控制變數將導致流程導向不一致；用作數組下標將會使程式崩潰；更加可能是造成其他變數的不準確而引起其他的錯誤。所以在聲明變數後馬上對其初始化一個預設的值是最簡單有效辦法，否則項目大了你找都沒地方找。

    debug版初始化成0xcc是因為0xcc在x86下是一條int 3單步中斷指令，這樣程式如果跑飛了遇到0xcc就會停下來，這和單片機編程時一般將沒用的代碼空間填入jmp 0000語句是一樣地。

5. MFC中自訂訊息的訊息參數
    在自訂訊息的函數體聲明時，時常會看到這樣的寫法:

    afx_msg LRESULT OnMessageOwn();

    Debug情況下一般不會有任何問題，而當你在Release下且多線程或進程間使用了訊息傳遞時就會導致無效控制代碼之類的錯誤。導致這個錯誤直接原因是訊息體的參數沒有添加，即應該寫成: 

    afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam);

6. release模式下不出錯，但debug模式下報錯

    這種情況下大多也是因為代碼書寫不正確引起的，查看MFC的源碼，可以發現好多ASSERT的語句(斷言)，這個宏只是在debug模式下才有效，那麼就清楚了，release版不報錯是忽略了錯誤而不是沒有錯誤，這可能存在很大的隱患，因為是Debug模式下，比較方便調試，好好的檢查自己的代碼，再此就不多說了。

常見的問題

1. 資料溢出的問題 

   1:  char buffer[10]; 

   2:  int counter; 

   3:  lstrcpy(buffer, "abcdefghik");

在debug版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M,什麼問題也沒有。但是在release版中，counter可能被放在寄存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函數的返回地址，這將導致ACCESS ERROR。

2. DEBUG版和RELEASE版的記憶體配置方式是不同的 

如果你在DEBUG版中申請ele為 6*sizeof(DWORD)=24bytes,實際上分配給你的是32bytes（debug版以32bytes為單位分配），而在release 版，分配給你的就是24bytes（release版以8bytes為單位), 所以在debug版中如果你寫ele[6],可能不會有什麼問題，而在release版中，就有ACCESS VIOLATE。

3. ASSERT在Release版本中是不會被編譯的

ASSERT宏是這樣定義的

   1:  #ifdef _DEBUG 

   2:  #define ASSERT(x) if( (x) == 0) report_assert_failure() 

   3:  #else 

   4:  #define ASSERT(x) 

   5:  #endif

實際上複雜一些，但無關緊要。

   1:  ASSERT(pNewObj = new CMyClass); 

   2:  pNewObj->MyFunction();

這種時候Release版本中的pNewObj不會分配到空間.所以執行到下一個語句的時候程式會報該程式執行了非法操作的錯誤。這時可以用VERIFY ：

   1:  #ifdef _DEBUG        

   2:  #define VERIFY(x) if( (x) == 0) report_assert_failure()          

   3:  #else          

   4:  #define VERIFY(x) (x)          

   5:  #endif

這樣的話，代碼在release版中就可以執行了。