VC 調試技巧全面又強大

作者：來源：csdn 發佈者：admin
時間：2009-07-07 10:45:35 點擊：713

1 前言

  當程序的運行結果與程序員預想的不一樣，如死機，計算值不正確，出現內存訪問衝突等，就需要進行調試

2 進行調試前的準備工作

  因爲程序調試是一項十分耗時的工作，很難估計出將要花費多長時間，因此在調試前，一定要做好充分準備，儘量避免做無用功：

構造好的測試步驟，讓程序出錯有規律性或出錯的概率越大越好
被調試程序及相關庫是最符合要求的版本
工程臨時文件如.ncb被刪除
整個工程被重新編譯
應用程序的鏈接路經與調試路徑保持一致
單體測試全部通過

3 出錯位置和原因的確定

3.1 幾種典型錯誤的原因

1 內存莫名其妙的失效

原因：內存指針被多處引用，被多處釋放

2 多線程條件下死機

原因：線程中由於用了SendMessage而造成死鎖，可人爲加入消息循環

3 多線程條件下內存訪問衝突

原因：內存被多個線程同時使用，可加入線程同步機制（用消息隊列，信號燈等）

4 內存訪問衝突

原因：內存越界（如字符串拷貝，內存拷貝）

5 窗口消息的次序問題

原因：如窗口未初始化就開始用

3.2 定位錯誤的位置

1 對代碼的理解越深，對代碼出錯位置的確定越精確，必要時應畫出相關代碼的類圖和時序圖

2 從IDE調用堆棧判斷出錯位置和原因

3 從Win32 API或MFC類庫函數的返回錯誤碼判斷出錯原因，返回錯誤碼的含義可以從MSDN或源代碼中找到，還可以通過VC工具Error lookup找到

4 在代碼中加入帶編號的TRACE語句或MessageBox(release版)，逐步縮小調試範圍

5 對於死機現象或偶發現象，可通過逐步註釋掉代碼的方法確定死機的位置和原因

6 如果死機現象或偶發現象是新出現的，可以通過比較目前版本和上一版本的差異來確定位置和原因

4 在debug方式下調試

4.1 調試的幾種技巧

4.1.1 使用ASSERT

ASSERT（ASSERT_VALID）宏僅在程序的“Debug”版本中捕捉程序錯誤。該宏在“Release”版本中不生成任何代碼。

4.1.2 使用TRACE

以下的例子只能在debug中顯示，

a) TRACE

CString csTest ＝ “test”；

TRACE（“CString is ％s/n”，csTest）；

b) ATLTRACE

c) AfxDump
AfxDump要求被dump的對象從CObject類繼承，並且實現了Dump的方法。

CTime time = CTime::GetCurrentTime();
#ifdef _DEBUG
afxDump << time << “/n”;
#endif

4.1.3 如何在循環語句中設置斷點

比如在下面的代碼中，當nRet == 0 時就認爲程序出錯。但是如何定位此時i的值爲幾呢。

1) 將光標定位在要調試的語句前面

2) CTRL+B，在Break at處選擇行號

3) 選擇Condition

在[Enter the expression…] 輸入 nRet == 0；點擊OK。運行程序，在彈出報錯對話框後點擊retry，程序執行將停在斷點處。這是可以看到循環變量的數值比如i此時等於9。表明i == 9的時候出的錯誤。

在CTRL+B，在[Enter the number of times…]輸入7，程序將在循環變量i = 8 時停下來。就可以進入出錯的函數進行調試了。

見：

VCDebugSample/src/DebugMain/DebugMainDlg.cpp—–

void CDebugMainDlg::OnButtonSetBkpt()

4.1.4 數據斷點（Data Breakpoint）

void CDebugMainDlg::OnButtonDataBkpt()

{

            // TODO: Add your control notification handler code here

            char szName1[10];

            char szName2[4];

            strcpy(szName1,"shenzhen");                       //A

            CString str1;

            str1.Format("%s/n", szName1);

            TRACE(str1);



            strcpy(szName2, "vckbase");             //B



            CString str2;

            str2.Format("%s/n", szName2);

            TRACE(str2);



            str1.Format("%s/n", szName1);

            TRACE(str1);#include "stdafx.h"

這段程序的輸出是

      sz1: shenzhe

      sz21: vckbase

      sz1: ase

szName1何時被修改呢？因爲沒有明顯的修改szName1代碼。我們可以首先在A行設置普通斷點，F5運行程序，程序停在A行。然後我們再設置一個數據斷點。如下圖：

F5繼續運行，程序停在B行，說明B處代碼修改了szName1。B處明明沒有修改szName1呀？但調試器指明是這一行，一般不會錯，所以還是靜下心來看看程序，哦，你發現了：szName2只有4個字節，而strcpy了7個字節，所以覆寫了szName1。
數據斷點不只是對變量改變有效，還可以設置變量是否等於某個值。譬如，你可以將Figure 2中紅圈處改爲條件”szName2[0]==””y””“,那麼當szName2第一個字符爲y時斷點就會啓動。
可以看出，數據斷點相對位置斷點一個很大的區別是不用明確指明在哪一行代碼設置斷點。

4.1.5 其他

1 在call stack窗口中設置斷點，選擇某個函數，按F9設置一個斷點。這樣可以從深層次的函數調用中迅速返回到需要的函數。
2 Set Next StateMent命令（debug過程中，右鍵菜單中的命令）
此命令的作用是將程序的指令指針（EIP）指向不同的代碼行。譬如，你正在調試上面那段代碼，運行在A行，但你不願意運行B行和C行代碼，這時，你就可以在 D行，右鍵，然後“Set Next StateMent”。調試器就不會執行B、C行。只要在同一函數內，此指令就可以隨意跳前或跳後執行。靈活使用此功能可以大量節省調試時間。
3 watch窗口
watch窗口支持豐富的數據格式化功能。如輸入0x65,u，則在右欄顯示101。
實時顯示windows API調用的錯誤：在左欄輸入@err,hr。
在watch窗口中調用函數。提醒一下，調用完函數後馬上在watch窗口中清除它，否則，單步調試時每一步調試器都會調用此函數。
4 messages斷點不怎麼實用。基本上可以用前面講述的斷點代替。

4.2 DLL的調試

4.2.1 DLL的測試與調試方法

DLL的測試與調試通常都要用到客戶端，在客戶端的調用DLL的API之前添加斷點，可以直接進入到DLL內部調試。

4.2.2 LoadLibrary失敗。

通常的原因是由於被加載的dll同時加載了其他dll或者組件，當這些dll或者組件不存在時loadLibrary不會成功。可以使用Visual studio tools-〉depends，將要加載的dll拖入到depends中，從裏面可以找出那些dll或者組件不存在。

4.2.3 註冊dll內部的COM組件時（Regsvr32）失敗。

絕大多數失敗也是由於加載dll不成功造成的。這是因爲在註冊dll內部的組件時，首先要加載此dll，如果加載失敗，也會導致regsvr32失敗，也可以採用上面的辦法。

4.3 COM的調試

4.3.1 跟蹤引用計數

若要在 ATL 中跟蹤引用數，請在包括 atlbase.h 之前添加以下代碼行：

#define _ATL_DEBUG_INTERFACES

該語句導致在每次調用 AddRef 或 Release 時，“輸出”窗口均顯示接口的當前引用數以及對應的類名和接口名稱。

可將斷點設置於：void CDebugMainDlg::OnButtonTraceRefcnt()

4.3.2 QueryInterface 調用調試

若要在 ATL 中調試 QueryInterface 調用，請在包括 atlcom.h 之前添加以下定義：

#define _ATL_DEBUG_QI

然後在調試時，在“輸出”窗口中查找在對象上查詢的每個接口的名稱。

可將斷點設置於：void CDebugMainDlg::OnButtonTraceQI()

4.4 多線程的調試

當涉及到多個線程通信時，要注意在正確的位置設置斷點。

見：

void CDebugMainDlg::OnButtonProcThd()

void CDebugMainDlg::OnButtonWinThd()

void CDebugMainDlg::OnButtonThdMsg()

在例子中首先啓動一個運行線程函數的線程（Thread1），啓動一個CWinThread類型的線程（Thread2），之後在OnButtonThdMsg函數中使用event通知Thread1，當 Thread1接收到event之後，使用ThreadMessage通知Thread2。實際上還有一個窗口的主線程，也就是 OnButtonThdMsg運行的線程，所以要想全程根中點擊button之後的運行情況，就要在各個線程中的恰當位置設置好斷點。

在程序的調試狀態，選擇debug->Threads，可以查看當前運行的線程，並可以讓某個線程掛起，繼續執行等。

5 Debug版與Release版的區別

Debug通常稱爲調試版本，它包含調試信息，並且不作任何優化，便於程序員調試程序。Release稱爲發佈版本，它往往是進行了各種優化，使得程序在代碼大小和運行速度上都是最優的，以便用戶很好地使用。

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

Debug 版本
參數含義
/MDd /MLd 或 /MTd 使用 Debug runtime library (調試版本的運行時刻函數庫)
/Od 關閉優化開關

/D “_DEBUG” 相當於 #define _DEBUG,打開編譯調試代碼開關 (主要針對assert函數)
/ZI 創建 Edit and continue(編輯繼續)數據庫，這樣在調試過程中如果修改了源代碼不需重新編譯
/GZ 可以幫助捕獲內存錯誤

Release 版本
參數含義
/MD /ML 或 /MT 使用發佈版本的運行時刻函數庫
/O1 或 /O2 優化開關，使程序最小或最快
/D “NDEBUG” 關閉條件編譯調試代碼開關 (即不編譯assert函數)
/GF 合併重複的字符串，並將字符串常量放到只讀內存，防止被修改

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

哪些情況下 Release 版會出錯

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

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

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

幀指針(Frame Pointer)省略（簡稱FPO）：在函數調用過程中，所有調用信息（返回地址、參數）以及自動變量都是放在棧中的。若函數的聲明與實現不同（參數、返回值、調用方式），就會產生錯誤，但 Debug 方式下，棧的訪問通過 EBP 寄存器保存的地址實現，如果沒有發生數組越界之類的錯誤（或是越界“不多”），函數通常能正常執行；Release 方式下，優化會省略 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)

},

volatile 型變量：volatile 告訴編譯器該變量可能被程序之外的未知方式修改（如系統、其他進程和線程）。優化程序爲了使程序性能提高，常把一些變量放在寄存器中（類似於 register 關鍵字），而其他進程只能對該變量所在的內存進行修改，而寄存器中的值沒變。

如果你的程序是多線程的，或者你發現某個變量的值與預期的不符而你確信已正確的設置了，則很可能遇到這樣的問題。這種錯誤有時會表現爲程序在最快優化出錯而最小優化正常。把你認爲可疑的變量加上 volatile 試試。

變量優化：優化程序會根據變量的使用情況優化變量。例如，函數中有一個未被使用的變量，在 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 並未其很大作用可能會被優化掉，從而使棧被破壞。

DEBUG 與 NDEBUG ：當定義了 _DEBUG 時，assert() 函數會被編譯，而 NDEBUG 時不被編譯。此外，TRACE() 宏的編譯也受 _DEBUG 控制。

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

順便值得一提的是VERIFY() 宏，這個宏允許你將程序代碼放在布爾表達式裏。這個宏通常用來檢查 Windows API的返回值。有些人可能爲這個原因而濫用VERIFY()，事實上這是危險的，因爲VERIFY()違反了斷言的思想，不能使程序代碼和調試代碼完全分離，最終可能會帶來很多麻煩。因此，專家們建議儘量少用這個宏。

/GZ 選項：這個選項會做以下這些事：
初始化內存和變量。包括用 0xCC 初始化所有自動變量，0xCD ( Cleared Data ) 初始化堆中分配的內存（即動態分配的內存，例如 new ），0xDD ( Dead Data ) 填充已被釋放的堆內存（例如 delete ），0xFD( deFencde Data ) 初始化受保護的內存（debug 版在動態分配內存的前後加入保護內存以防止越界訪問），其中括號中的詞是微軟建議的助記詞。這樣做的好處是這些值都很大，作爲指針是不可能的（而且 32 位系統中指針很少是奇數值，在有些系統中奇數的指針會產生運行時錯誤），作爲數值也很少遇到，而且這些值也很容易辨認，因此這很有利於在 Debug 版中發現 Release 版纔會遇到的錯誤。要特別注意的是，很多人認爲編譯器會用0來初始化變量，這是錯誤的（而且這樣很不利於查找錯誤）。
通過函數指針調用函數時，會通過檢查棧指針驗證函數調用的匹配性。（防止原形不匹配）
函數返回前檢查棧指針，確認未被修改。（防止越界訪問和原形不匹配，與第二項合在一起可大致模擬幀指針省略 FPO ）通常 /GZ 選項會造成 Debug 版出錯而 Release 版正常的現象，因爲 Release 版中未初始化的變量是隨機的，這有可能使指針指向一個有效地址而掩蓋了非法訪問。除此之外，/Gm/GF等選項造成錯誤的情況比較少，而且他們的效果顯而易見，比較容易發現。

怎樣“調試” Release 版的程序

在編程過程中就要時常注意測試 Release 版本，以免最後代碼太多，時間又很緊。
在 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。

release方式下調試

  當程序在Release下出錯，而在debug下不出錯時，就需要用到release方式下的調試技術。在用release方式下的調試技術之前，對代碼進行如下檢查：

1 release方式下沒有代碼被註釋掉，如ASSERT(a=f()); TRACE(f());在release下是會被註釋掉的。

2 檢查所有的變量是否被初始化

3 檢查邊界錯誤，如以下代碼：

void func()

    {
     char buffer[10];
     int counter;
     lstrcpy(buffer, "abcdefghik"); // 11-byte copy, including NULL
     ...

release方式下的調試技術：

1 在VC IDE中選擇Project Settings (Alt-F2)，在 “C++/C tab” 中設置 category爲 “General”將Debug Info setting 改爲”Program Database”.

2 在”Link tab”中選中”Generate Debug Info” tab.

3 執行”Rebuild All”

注意：

  1 有時也需要禁止release方式下的優化選項
  2 如果有些代碼段無法設置斷點，可以加入如下代碼：

    __asm {int 3};

     效果與Debug方式下的ASSERT(FALSE)類似
  當一個應用程序是被另一個應用程序啓動時，或者多個應用程序之間進行交互，就要用到多進程調試技術，方法是：

1 啓動任務管理器，選擇要調試的進程，點擊鼠標右鍵，選擇debug

2 啓動VC IDE,選擇下圖所示的菜單，在選擇相應的進程

注意：這裏有一個問題，可能我們想要設斷點的代碼在進程能夠調試前已經執行過，無法設斷點，解決辦法有兩個：

1 在設斷點的代碼加入代碼

 ASSERT(FALSE);

進程運行時會出現下述對話框，選擇retry就可以進行調試

2 在設斷點的代碼加入代碼

  AfxMessageBox(“debug”);//debug是任意的

進程運行時會出現對話框，此時attach改進成就可以進行調試

當多個進程同時處於調試狀態，我們就可以從各自的調試窗口看到TRACE信息。

WM_MOUSEMOVE 消息的調試：

很多情況下如果不加條件的直接在MouseMove 響應函數內消息設置斷點，並不方便調試，比如當鼠標在移動到某一區域內出錯的情況，就無法利用斷點跟蹤，這時候可以在程序中，多添加一些TRACE語句，來定位，對於Release版還有可以用log工具輸出到log文件，如果沒有現成的log工具可以用，也可以自己編寫一個非常簡單的log工具。

PreTranslateMessage，HookMessage，與上面的情況類似。

8.2 使用Spy++中簡單的功能

8.2.1 Finder Tool

Visual studio tools->Spy++->ctrl+F

將圓圈圖標拖動到目標窗口上，可以在下面看到有關窗口的一些信息。

Caption：窗口的標題。

Class：類明。

Style：窗口風格：

Rect：窗口的位置和大小

8.2.2 察看窗口的各種屬性

在上面的窗口中選擇Properties radio button->OK，可以在下面的窗口中查看各種信息。

8.2.3 察看窗口的消息

若在途中選擇Messages radio button->OK->ctrl+o,

上面的途中列出了所有可以看到的消息，若只關心某一類消息，比如，鼠標消息。

則點擊Clear ALL，然後在右面只選中Mouse check box.

單擊OK。

則所有有關鼠標的消息，都可以顯示在輸出窗口上。如果只想跟蹤WM_LBUTTONDOWN的消息，則在左側Messages to View框中，只選中WM_LBUTTONDOWN.

如果想監視某一個空間，比如button，則可以將finder tool定位在那個button上。然後按照上面的步驟進行設置。

9 總結

調試最重要的還是你要思考，要猜測你的程序可能出錯的地方，然後運用你的調試器來證實你的猜測。而熟練使用上面這些技巧無疑會加快這個過程。另外在調試過程中，不要侷限於一種方法，將幾個方法結合在一起使用，可以加快錯誤定位的速度，以便較快的解決問題。

VC 調試技巧全面又強大

MySQL 核心模塊揭祕 | 18 期 | 鎖在內存里長什麼樣*

使用perf工具生成火焰圖

HttpSecurity 是如何組裝過濾器鏈的

數說海南——近6年海南各市縣人口簡單看

長序列中Transformers的高級注意力機制總結

大齡程序員思考

響應式界面控件DevExtreme * 更強的數據分析和可視化功能

Windows、字符集和_T宏

dump code

MFC中CtreeCtrl控件實現三態複選的總結

[轉]ProcessExplorer使用分享

log4cpp用法

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

VC 調試技巧 全面又強大

VC 調試技巧全面又強大