• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            調(diào)試技巧之調(diào)用堆棧

            簡單介紹

            調(diào)試是程序開發(fā)者必備技巧。如果不會調(diào)試,自己寫的程序一旦出問題,往往無從下手。本人總結(jié)10年使用VC經(jīng)驗,對調(diào)試技巧做一個粗淺的介紹。希望對大家有所幫助。

            今天簡單的介紹介紹調(diào)用堆棧。調(diào)用堆棧在我的專欄的文章VC調(diào)試入門提了一下,但是沒有詳細介紹。

            首先介紹一下什么叫調(diào)用堆棧:假設(shè)我們有幾個函數(shù),分別是function1,function2,function3,funtion4,且function1調(diào)用function2,function2調(diào)用function3,function3調(diào)用function4。在function4運行過程中,我們可以從線程當(dāng)前堆棧中了解到調(diào)用他的那幾個函數(shù)分別是誰。把函數(shù)的順序關(guān)系看,function4、function3、function2、function1呈現(xiàn)出一種“堆棧”的特征,最后被調(diào)用的函數(shù)出現(xiàn)在最上方。因此稱呼這種關(guān)系為調(diào)用堆棧(call stack)。

            當(dāng)故障發(fā)生時,如果程序被中斷,我們基本上只可以看到最后出錯的函數(shù)。利用call stack,我們可以知道當(dāng)出錯函數(shù)被誰調(diào)用的時候出錯。這樣一層層的看上去,有時可以猜測出錯誤的原因。常見的這種中斷時ASSERT宏導(dǎo)致的中斷。

            在程序被中斷時,debug工具條的右側(cè)倒數(shù)第二個按鈕一般是call stack按鈕,這個按鈕被按下后,你就可以看到當(dāng)前的調(diào)用堆棧。

            實例一:介紹

            我們首先演示一下調(diào)用堆棧。首先我們創(chuàng)建一個名為Debug的對話框工程。工程創(chuàng)建好以后,雙擊OK按鈕創(chuàng)建消息映射函數(shù),并添加如下代碼:

            void CDebugDlg::OnOK() 
            { 
            
            // TODO: Add extra validation here ASSERT(FALSE);
            }

            我們按F5開始調(diào)試程序。程序運行后,點擊OK按鈕,程序就會被中斷。這時查看call stack窗口,就會發(fā)現(xiàn)內(nèi)容如下:

            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作為整個調(diào)用鏈中最后被調(diào)用的函數(shù)出現(xiàn)在call stack的最上方,而內(nèi)核中程序的啟動函數(shù)Kernel32! 7c816d4f()則作為棧底出現(xiàn)在最下方。

            實例二:學(xué)習(xí)處理方法

            微軟提供了MDI/SDI模型提供文檔處理的建議結(jié)構(gòu)。有些時候,大家希望控制某個環(huán)節(jié)。例如,我們希望彈出自己的打開文件對話框,但是并不想自己實現(xiàn)整個文檔的打開過程,而更愿意MFC完成其他部分的工作。可是,我們并不清楚MFC是怎么處理文檔的,也不清楚如何插入自定義代碼。

            幸運的是,我們知道當(dāng)一個文檔被打開以后,系統(tǒng)會調(diào)用CDocument派生類的Serialize函數(shù),我們可以利用這一點來跟蹤MFC的處理過程。

            我們首先創(chuàng)建一個缺省的SDI工程Test1,并在CTest1Doc::Serialize函數(shù)的開頭增加一個斷點,運行程序,并打開一個文件。這時,我們可以看到調(diào)用堆棧是(我只截取了感興趣的一段):

            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
            

            從上面的調(diào)用堆??矗@個過程由一個WM_COMMAND消息觸發(fā)(因為我們用菜單打開文件),由CWinApp::OnFileOpen最先開始實際處理過程,這個函數(shù)調(diào)用CDocManager::OnFileOpen打開文檔。

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

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

            m_pDocManager是一個CDocManager類的實例指針,我們雙擊CDocManager::OnFileOpen行,看該函數(shù)的實現(xiàn):

            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
            }
            

            很顯然,該函數(shù)首先調(diào)用DoPromptFileName函數(shù)來獲得一個文件名,然后在繼續(xù)后續(xù)的打開過程。

            順這這個線索下去,我們一定能找到插入我們文件打開對話框的位置。由于這不是我們研究的重點,后續(xù)的分析我就不再詳述。

            實例三:內(nèi)存訪問越界

            在Debug版本的VC程序中,程序會給每塊new出來的內(nèi)存,預(yù)留幾個字節(jié)作為越界檢測之用。在釋放內(nèi)存時,系統(tǒng)會檢查這幾個字節(jié),判斷是否有內(nèi)存訪問越界的可能。

            我們借用前一個實例程序,在CTest1App::InitInstance的開頭添加以下幾行代碼:

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

            很顯然,這段代碼申請了10字節(jié)內(nèi)存,但是使用了100字節(jié)。我們在memset(p,0,100);這行加一個斷點,然后執(zhí)行程序,斷點到達后,我們觀察p指向的內(nèi)存的值(利用Debug工具條的Memory功能),可以發(fā)現(xiàn)它的值是:

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

            根據(jù)經(jīng)驗,p實際被分配了16個字節(jié),后6個字節(jié)用于保護。我們按F5全速執(zhí)行程序,會發(fā)現(xiàn)如下的錯誤信息被彈出:

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

            該信息提示,在正常內(nèi)存塊0x00421AB0后的內(nèi)存被破壞(內(nèi)存訪問越界),我們點擊Retry進入調(diào)試狀態(tài),發(fā)現(xiàn)調(diào)用堆棧是:

            _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
            

            很顯然,這個錯誤是在調(diào)用delete時遇到的,出現(xiàn)在CTest1App::InitInstance() line 54 + 15 bytes之處。我們很容易根據(jù)這個信息找到,是在釋放哪塊內(nèi)存時出現(xiàn)問題,之后,我們只需要根據(jù)這個內(nèi)存的訪問過程確定哪兒出錯,這將大大降低調(diào)試的難度。

            實例四:子類化

            子類化是我們修改一個現(xiàn)有控件實現(xiàn)新功能的常用方法,我們借用實例一中的Debug對話框工程來演示我過去學(xué)習(xí)子類化的一個故事。我們創(chuàng)建一個缺省的名為Debug的對話框工程,并按照下列步驟進行實例化:

            1. 在對話框資源中增加一個Edit控件
            2. 用class wizard為CEdit派生一個類CMyEdit(由于今天不關(guān)心子類化的具體細節(jié),因此這個類不作任何修改)
            3. 為Edit控件,增加一個控件類型變量m_edit,其類型為CMyEdit
            4. 在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進入調(diào)試狀態(tài),我們可以看到調(diào)用堆棧為:

            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句柄時出現(xiàn)問題,出問題行的代碼為:

                ASSERT(m_hWnd == NULL);  
            

            這說明我們在子類化時不應(yīng)該綁定控件,我們刪除CDebugDialog::DoDataExchange中的下面一行:

                DDX_Control(pDX, IDC_EDIT1, m_edit);
            
            問題就得到解決

            總結(jié)

            簡而言之,call stack是調(diào)試中必須掌握的一個技術(shù),但是程序員需要豐富的經(jīng)驗才能很好的掌握和使用它。你不僅僅需要熟知C++語法,還需要對相關(guān)的平臺、軟件設(shè)計思路有一定的了解。我的文章只能算一個粗淺的介紹,畢竟我在這方面也不算高手。希望對新進有一定的幫助。

            posted on 2006-07-11 13:39 楊粼波 閱讀(356) 評論(0)  編輯 收藏 引用

            亚洲精品综合久久| 久久青青草原综合伊人| 2021最新久久久视精品爱| 77777亚洲午夜久久多喷| 亚洲av日韩精品久久久久久a| 久久国产乱子伦免费精品| 欧美久久综合性欧美| 国产免费久久精品99re丫y| 精品久久久久久亚洲精品| 香港aa三级久久三级老师2021国产三级精品三级在 | 99久久久精品免费观看国产| 91精品国产综合久久香蕉| 色妞色综合久久夜夜| 亚洲伊人久久大香线蕉苏妲己| 久久国产免费直播| 午夜福利91久久福利| 久久九九青青国产精品| 久久精品国产亚洲av麻豆小说| 中文国产成人精品久久亚洲精品AⅤ无码精品 | 青青久久精品国产免费看| 国产成人无码精品久久久免费| 尹人香蕉久久99天天拍| 亚洲国产成人精品女人久久久 | 久久精品国产亚洲精品2020| 大香伊人久久精品一区二区| 久久久国产精华液| 99国内精品久久久久久久 | 久久久亚洲精品蜜桃臀| 人人狠狠综合久久亚洲婷婷 | 欧美久久综合九色综合| 国产三级精品久久| 国产福利电影一区二区三区久久久久成人精品综合 | 国产精品99久久久精品无码| 思思久久99热只有频精品66| 伊人久久精品影院| 久久毛片一区二区| 久久久这里有精品| 婷婷五月深深久久精品| 99久久成人国产精品免费| 国产午夜精品理论片久久影视| 97久久精品无码一区二区天美|