除錯是程式開發者必備技巧。如果不會除錯，自己寫的程式一旦出問題，往往無從下手。本人總結10年使用VC經驗，對除錯技巧做一個粗淺的介紹。希望對大家有所幫助。

今天簡單的介紹介紹呼叫堆疊。呼叫堆疊在我的專欄的文章VC除錯入門提了一下，但是沒有詳細介紹。

首先介紹一下什麼叫呼叫堆疊：假設我們有幾個函式，分別是function1,function2,function3,funtion4，且function1呼叫function2，function2呼叫function3，function3呼叫function4。在function4執行過程中，我們可以從執行緒當前堆疊中瞭解到呼叫他的那幾個函式分別是誰。把函式的順序關係看，function4、function3、function2、function1呈現出一種“堆疊”的特徵，最後被呼叫的函數出現在最上方。因此稱呼這種關係為呼叫堆疊(call stack)。

當故障發生時，如果程式被中斷，我們基本上只可以看到最後出錯的函式。利用call stack，我們可以知道當出錯函式被誰呼叫的時候出錯。這樣一層層的看上去，有時可以猜測出錯誤的原因。常見的這種中斷時ASSERT巨集導致的中斷。

在程式被中斷時，debug工具條的右側倒數第二個按鈕一般是call stack按鈕，這個按鈕被按下後，你就可以看到當前的呼叫堆疊。

例項一：介紹
我們首先演示一下呼叫堆疊。首先我們建立一個名為Debug的對話方塊工程。工程建立好以後，雙擊OK按鈕建立訊息對映函式，並新增如下程式碼： 

void CDebugDlg::OnOK() 
{ 

// TODO: Add extra validation here 
ASSERT(FALSE); 

} 

我們按F5開始除錯程式。程式執行後，點選OK按鈕，程式就會被中斷。這時檢視call stack視窗，就會發現內容如下： 

CDebugDlg::OnOK() line 176 + 34 bytes
_AfxDispatchCmdMsg(CCmdTarget * 0x0012fe74 {CDebugDlg}, unsigned int 1, int 0, void (void)* 0x5f402a00 `vcall'(void), void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88
CCmdTarget::OnCmdMsg(unsigned int 1, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000) line 302 + 39 bytes
CDialog::OnCmdMsg(unsigned int 1, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000) line 97 + 24 bytes
CWnd::OnCommand(unsigned int 1, long 656988) line 2088
CWnd::OnWndMsg(unsigned int 273, unsigned int 1, long 656988, long * 0x0012f83c) line 1597 + 28 bytes
CWnd::WindowProc(unsigned int 273, unsigned int 1, long 656988) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x0012fe74 {CDebugDlg hWnd=???}, HWND__ * 0x001204b0, unsigned int 273, unsigned int 1, long 656988) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x001204b0, unsigned int 273, unsigned int 1, long 656988) line 368
AfxWndProcBase(HWND__ * 0x001204b0, unsigned int 273, unsigned int 1, long 656988) line 220 + 21 bytes
USER32! 77d48709()
USER32! 77d487eb()
USER32! 77d4b368()
USER32! 77d4b3b4()
NTDLL! 7c90eae3()
USER32! 77d4b7ab()
USER32! 77d7fc9d()
USER32! 77d76530()
USER32! 77d58386()
USER32! 77d5887a()
USER32! 77d48709()
USER32! 77d487eb()
USER32! 77d489a5()
USER32! 77d489e8()
USER32! 77d6e819()
USER32! 77d65ce2()
CWnd::IsDialogMessageA(tagMSG * 0x004167d8 {msg=0x00000202 wp=0x00000000 lp=0x000f001c}) line 182
CWnd::PreTranslateInput(tagMSG * 0x004167d8 {msg=0x00000202 wp=0x00000000 lp=0x000f001c}) line 3424
CDialog::PreTranslateMessage(tagMSG * 0x004167d8 {msg=0x00000202 wp=0x00000000 lp=0x000f001c}) line 92
CWnd::WalkPreTranslateTree(HWND__ * 0x001204b0, tagMSG * 0x004167d8 {msg=0x00000202 wp=0x00000000 lp=0x000f001c}) line 2667 + 18 bytes
CWinThread::PreTranslateMessage(tagMSG * 0x004167d8 {msg=0x00000202 wp=0x00000000 lp=0x000f001c}) line 665 + 18 bytes
CWinThread::PumpMessage() line 841 + 30 bytes
CWnd::RunModalLoop(unsigned long 4) line 3478 + 19 bytes
CDialog::DoModal() line 536 + 12 bytes
CDebugApp::InitInstance() line 59 + 8 bytes
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00141f00, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00141f00, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 7c816d4f()

這裡，CDebugDialog::OnOK作為整個呼叫鏈中最後被呼叫的函數出現在call stack的最上方，而核心中程式的啟動函式Kernel32! 7c816d4f()則作為棧底出現在最下方。

例項二：學習處理方法
微軟提供了MDI/SDI模型提供文件處理的建議結構。有些時候，大家希望控制某個環節。例如，我們希望彈出自己的開啟檔案對話方塊，但是並不想自己實現整個文件的開啟過程，而更願意MFC完成其他部分的工作。可是，我們並不清楚MFC是怎麼處理文件的，也不清楚如何插入自定義程式碼。

幸運的是，我們知道當一個文件被開啟以後，系統會呼叫CDocument派生類的Serialize函式，我們可以利用這一點來跟蹤MFC的處理過程。

我們首先建立一個預設的SDI工程Test1，並在CTest1Doc::Serialize函式的開頭增加一個斷點，執行程式，並開啟一個檔案。這時，我們可以看到呼叫堆疊是(我只截取了感興趣的一段)： 

CTest1Doc::Serialize(CArchive & {...}) line 66
CDocument::OnOpenDocument(const char * 0x0012f54c) line 714
CSingleDocTemplate::OpenDocumentFile(const char * 0x0012f54c, int 1) line 168 + 15 bytes
CDocManager::OpenDocumentFile(const char * 0x0042241c) line 953
CWinApp::OpenDocumentFile(const char * 0x0042241c) line 93
CDocManager::OnFileOpen() line 841
CWinApp::OnFileOpen() line 37
_AfxDispatchCmdMsg(CCmdTarget * 0x004177f0 class CTest1App  theApp, unsigned int 57601, int 0, void (void)* 0x00402898 CWinApp::OnFileOpen, void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88
CCmdTarget::OnCmdMsg(unsigned int 57601, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000) line 302 + 39 bytes
CFrameWnd::OnCmdMsg(unsigned int 57601, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000) line 899 + 33 bytes
CWnd::OnCommand(unsigned int 57601, long 132158) line 2088
CFrameWnd::OnCommand(unsigned int 57601, long 132158) line 317


從上面的呼叫堆疊看，這個過程由一個WM_COMMAND訊息觸發（因為我們用選單開啟檔案)，由CWinApp::OnFileOpen最先開始實際處理過程，這個函式呼叫CDocManager::OnFileOpen開啟文件。

我們首先雙擊CWinApp::OnFileOpen() line 37開啟CWinApp::OnFileOpen，它的處理過程是： 

    ASSERT(m_pDocManager != NULL);
    m_pDocManager->OnFileOpen();

m_pDocManager是一個CDocManager類的例項指標，我們雙擊CDocManager::OnFileOpen行，看該函式的實現： 

void CDocManager::OnFileOpen()
{
 // prompt the user (with all document templates)
 CString newName;
 if (!DoPromptFileName(newName, AFX_IDS_OPENFILE,
   OFN_HIDEREADONLY | OFN_FILEMUSTEXIST, TRUE, NULL))
  return; // open cancelled
 AfxGetApp()->OpenDocumentFile(newName);
  // if returns NULL, the user has already been alerted
}

很顯然，該函式首先呼叫DoPromptFileName函式來獲得一個檔名，然後在繼續後續的開啟過程。

順這這個線索下去，我們一定能找到插入我們檔案開啟對話方塊的位置。由於這不是我們研究的重點，後續的分析我就不再詳述。

例項三：記憶體訪問越界
在Debug版本的VC程式中，程式會給每塊new出來的記憶體，預留幾個位元組作為越界檢測之用。在釋放記憶體時，系統會檢查這幾個位元組，判斷是否有記憶體訪問越界的可能。

我們借用前一個例項程式，在CTest1App::InitInstance的開頭新增以下幾行程式碼： 

    char * p = new char[10];
    memset(p,0,100);
    delete []p;
    return FALSE;

很顯然，這段程式碼申請了10位元組記憶體，但是使用了100位元組。我們在memset(p,0,100);這行加一個斷點，然後執行程式，斷點到達後，我們觀察p指向的記憶體的值(利用Debug工具條的Memory功能)，可以發現它的值是：

  CD CD CD CD CD CD CD CD
  CD CD FD FD FD FD FD FD
  00 00 00 00 00 00 00 00
  ......

根據經驗，p實際被分配了16個位元組，後6個位元組用於保護。我們按F5全速執行程式，會發現如下的錯誤資訊被彈出： 

   Debug Error!
   Program: c:/temp/test1/Debug/test1.exe
   DAMAGE: after normal block (#55) at 0x00421AB0
   Press Retry to debug the application

該資訊提示，在正常記憶體塊0x00421AB0後的記憶體被破壞（記憶體訪問越界），我們點選Retry進入除錯狀態，發現呼叫堆疊是： 

_free_dbg_lk(void * 0x00421ab0, int 1) line 1033 + 60 bytes
_free_dbg(void * 0x00421ab0, int 1) line 970 + 13 bytes
operator delete(void * 0x00421ab0) line 351 + 12 bytes
CTest1App::InitInstance() line 54 + 15 bytes

很顯然，這個錯誤是在呼叫delete時遇到的，出現在CTest1App::InitInstance() line 54 + 15 bytes之處。我們很容易根據這個資訊找到，是在釋放哪塊記憶體時出現問題，之後，我們只需要根據這個記憶體的訪問過程確定哪兒出錯，這將大大降低除錯的難度。

例項四：子類化
子類化是我們修改一個現有控制元件實現新功能的常用方法，我們借用例項一中的Debug對話方塊工程來演示我過去學習子類化的一個故事。我們建立一個預設的名為Debug的對話方塊工程，並按照下列步驟進行例項化： 

在對話方塊資源中增加一個Edit控制元件 
用class wizard為CEdit派生一個類CMyEdit（由於今天不關心子類化的具體細節，因此這個類不作任何修改） 
為Edit控制元件，增加一個控制元件型別變數m_edit，其型別為CMyEdit 
在OnInitDialog中增加如下語句： 

m_edit.SubclassDlgItem(IDC_EDIT1,this);

我們執行這個程式，會遇到這樣的錯誤： 


Debug Assertion Failed!
Application:C:/temp/Debug/Debug/Debug.exe
File:Wincore.cpp
Line:311

For information on how your program can cause an assertion failure, see Visual C++ documentation on asserts.

(Press Retry to debug the application)

點選Retry進入除錯狀態，我們可以看到呼叫堆疊為： 

CWnd::Attach(HWND__ * 0x000205a8) line 311 + 28 bytes
CWnd::SubclassWindow(HWND__ * 0x000205a8) line 3845 + 12 bytes
CWnd::SubclassDlgItem(unsigned int 1000, CWnd * 0x0012fe34 {CDebugDlg hWnd=0x001d058a}) line 3883 + 12 bytes
CDebugDlg::OnInitDialog() line 120

可以看出在Attach控制代碼時出現問題，出問題行的程式碼為： 

    ASSERT(m_hWnd == NULL);  

這說明我們在子類化時不應該繫結控制元件，我們刪除CDebugDialog::DoDataExchange中的下面一行： 

    DDX_Control(pDX, IDC_EDIT1, m_edit);

問題就得到解決

總結
簡而言之，call stack是除錯中必須掌握的一個技術，但是程式設計師需要豐富的經驗才能很好的掌握和使用它。你不僅僅需要熟知C++語法，還需要對相關的平臺、軟體設計思路有一定的瞭解。我的文章只能算一個粗淺的介紹，畢竟我在這方面也不算高手。希望對新進有一定的幫助。