• <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>
            posts - 62,  comments - 19,  trackbacks - 0
            作為程序員,平時最擔心見到的事情就是程序發生了崩潰,無論是指針越界還是非法操作,都將給我們的應用系統造成巨大的損失。但在一個大型系統的測試過程中,初期出現程序崩潰似乎成了不可避免的事。其實測試中出現程序崩潰并不可怕,反而是測試的成功。我們更為關心的是程序中的哪一行導致了系統崩潰,這樣我們才能有針對性的進行改正。
              在VC中,我們可以利用出現程序崩潰時VC的自動跳轉,定位到出錯代碼行。但在大量的壓力測試時,尤其是多線程測試時,同時出現幾十個錯,這時VC本身的出錯跳轉往往會失靈。
              在這里我們介紹一種輔助查找程序崩潰代碼行的好方法,它的核心就是利用編譯時生成MAP文件中的信息來定位代碼行。
            下面就開始我們的介紹。
              首先我們必須生成程序的MAP文件。那么什么是 MAP 文件呢?簡單地講, MAP 文件是程序的全局符號、源文件和代碼行號信息的唯一的文本表示方法,是整個程序工程信息的靜態文本。它可以在任何地方、任何時候使用,不需要有額外的程序進行支持,僅僅通過一個文本閱讀工具如Ultra Edit就可以打開了。而且,這是唯一能找出程序崩潰代碼行的救星。
              那么我們應該如何生成MAP文件呢?在 VC 中,我們可以按下 Alt+F7,打開“Project Settings”選項頁,選擇 C/C++ 選項卡,并在最下面的 Project Options 里面輸入:/Zd ,然后要選擇 Link 選項卡,選中“Generate mapfile”復選框,并在最下面的 Project Options 里面輸入:/mapinfo:lines,表示生成 MAP 文件時,加入行信息。最后按下 F7 來編譯生成 EXE 可執行文件和 MAP 文件,此時可以在工程的Debug目錄下找到剛剛生成的MAP文件,文件名為“工程名.map”。
              通過上面的步驟,已經得到了 MAP 文件,那么我們該如何利用它呢?讓我們從一個簡單的實例入手,一步一步演示使用MAP文件定位程序崩潰行的過程。
            首先假設我們的VC工程中有下面這個文件:
            //*****************************************************
            // 程序名稱:演示如何通過崩潰地址找出源代碼的出錯行
            // 作者:劉可
            // 日期:2003-6-19
            // 本程序會產生“除0錯誤”,所以會導致
            // 程序崩潰,彈出“非法操作”對話框。
            //******************************************************
            #include

            int crashtest(int a,int b)
            {
            int c;
            c = a/b;
            return c;
            }

            void main(void)
            {
            int a = 30;
            int b = 0;
            int ret;
            printf("let's begin crash test...\n");
            ret = crashtest(a,b);
            }

            很顯然本程序有“除0錯誤”,在 Debug 方式下編譯,運行時會產生“非法操作”。我們記錄下產生崩潰的地址——在我的機器上是 0x0040102f 。這個在不同的機器上可能地址不同,但記下這個地址我們下面將要使用。
            我們打開它的 MAP 文件:(這里列出我們比較關心的內容,其他的就略過了)

            abort(工程名)

            Timestamp is 3ef16533 (Thu Jun 19 15:24:35 2003)

            Preferred load address is 00400000

            Start    Length    Name        Class
            0001:00000000 0001081dH .text        CODE
            0002:00000000 000013baH .rdata        DATA
            0002:000013ba 00000000H .edata        DATA
            0003:00000000 00000104H .CRT$XCA       DATA
            0003:00000104 00000104H .CRT$XCZ       DATA
            0003:00000208 00000104H .CRT$XIA       DATA
            0003:0000030c 00000109H .CRT$XIC       DATA
            0003:00000418 00000104H .CRT$XIZ       DATA
            0003:0000051c 00000104H .CRT$XPA       DATA
            0003:00000620 00000104H .CRT$XPX       DATA
            0003:00000724 00000104H .CRT$XPZ       DATA
            0003:00000828  00000104H .CRT$XTA       DATA
            0003:0000092c  00000104H .CRT$XTZ       DATA
            0003:00000a30  00003236H .data        DATA
            0003:00003c68  000019c8H .bss        DATA
            0004:00000000  00000014H .idata$2       DATA
            0004:00000014  00000014H .idata$3       DATA
            0004:00000028  00000120H .idata$       DATA
            0004:00000148  00000120H .idata$5        DATA
            0004:00000268  000004f4H .idata$6       DATA

            Address Publics by Value Rva+Base Lib:Object

            0001:00000020 ?crashtest@@YAHHH@Z 00401020 f main.obj
            0001:0000003c _main 0040103c f main.obj
            0001:000000b0 _printf 004010b0 f LIBCD:printf.obj
            0001:00000130 __chkesp 00401130 f LIBCD:chkesp.obj
            0001:00000170 _mainCRTStartup 00401170 f LIBCD:crt0.obj
            0001:000002a0 __amsg_exit 004012a0 f LIBCD:crt0.obj
            0001:00000300 __stbuf 00401300 f LIBCD:_sftbuf.obj
            0001:00000460 __ftbuf 00401460 f LIBCD:_sftbuf.obj
            0001:00000520 __output 00401520 f LIBCD:output.obj
            0001:000013c0 ___initstdio 004023c0 f LIBCD:_file.obj
            0001:000014f0 ___endstdio 004024f0 f LIBCD:_file.obj
            0001:00001510 __CrtDbgBreak 00402510 f LIBCD:dbgrpt.obj
            0001:00001520 __CrtSetReportMode 00402520 f LIBCD:dbgrpt.obj
            0001:00001580 __CrtSetReportFile 00402580 f LIBCD:dbgrpt.obj
            0001:00001600 __CrtSetReportHook 00402600 f LIBCD:dbgrpt.obj
            0001:00001620 __CrtDbgReport 00402620 f LIBCD:dbgrpt.obj

              如果仔細瀏覽 Rva+Base 這欄,我們可以發現第一個比崩潰地址 0x0040102f 大的函數地址是 0x0040103c ,所以在 0x0040103c 這個地址之前的那個入口就是產生崩潰的函數,也就是這行:

            0001:00000020 ?crashtest@@YAHHH@Z 00401020 f main.obj

              因此,發生崩潰的函數就是 ?crashtest@@YAHHH@Z,所有以問號開頭的函數名稱都是 C++ 修飾的名稱。所以在我們的源程序中,這個發生崩潰的函數就是 crashtest ()!

              現在我們便輕而易舉地知道了發生崩潰的函數名稱。把它記下來,然后我們將要直接定位發生崩潰的代碼行了。我們注意 MAP 文件的最后部分——代碼行信息(Line numbers information),它是以這樣的形式顯示的:

            Line numbers for .\Debug\main.obj(D:\我的工作\技術\出異常例子abort\main.cpp) segment .text

            12 0001:00000020 14 0001:0000002b 15 0001:00000035 16 0001:00000038
            19 0001:0000003c 20 0001:00000057 21 0001:0000005e 23 0001:00000065
            24 0001:00000072 25 0001:00000085

              第一個數字代表在源代碼中的代碼行號,第二個數是該代碼行在所屬的代碼段中的偏移量。如果要查找代碼行號,需要使用下面的公式做一些十六進制的減法運算:

            崩潰行偏移 = 崩潰地址(Crash Address)- 基地址(ImageBase Address)- 0x1000

              為什么要這樣做呢?因為我們得到的崩潰地址都是由 偏移地址(Rva)+ 基地址(Base)得來的,所以在計算行號的時候要把基地址減去。一般情況下,基地址的值是 0x00400000 。另外,由于一般的 PE 文件的代碼段都是從 0x1000 偏移開始的,所以也必須減去 0x1000 。
              所以我們的:崩潰行偏移 = 0x0040102f - 0x00400000 - 0x1000 = 0x2f
            我們在MAP 文件的中的代碼行信息里查找不超過計算結果0x2f,但卻最接近的數。發現是 main.cpp 文件中的:

            14 0001:0000002b

              也就意味著在源代碼中的第 14 行!讓我們來看看源代碼,注意注釋行和空行也要計算在內,程序的第14行為:

            c = a/b;

            果然就是第 14 行啊,它發生了“除0異常”!

              方法已經介紹完了,從今以后,我們就可以精確地定位到源代碼中的崩潰行,而且只要編譯器可以生成 MAP 文件,無論在WIN平臺還是UNIX平臺,本方法都是適用的。
              本文我們只是列舉了一個非常簡單的“除0異常”例子,使用MAP文件的效力或許還不十分明顯。但相信在我們的大型應用系統調試中,使用MAP文件的輔助方法來快速定位發生程序崩潰的函數以及代碼行,將會為我們的程序調試工作節省大量時間和精力,提高我們的調試質量。我們甚至可以要求遠地用戶直接提供程序崩潰的地址,然后就可以在自己機器上利用MAP文件靜態地找到出錯的那行,并在程序中進行相應修正了。

            &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

            VC7下運行OK.


            posted on 2007-03-26 10:37 喬棟 閱讀(801) 評論(0)  編輯 收藏 引用 所屬分類: C++的健身房
            <2006年12月>
            262728293012
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜


            My blog is worth $0.00.
            How much is your blog worth?

            国产精品久久久久久久久鸭| 久久久久黑人强伦姧人妻| 伊人久久无码中文字幕| 日产精品99久久久久久| 久久久久久狠狠丁香| 久久婷婷五月综合色99啪ak| 欧美精品国产综合久久| 精品国产一区二区三区久久久狼 | 2021精品国产综合久久| 午夜不卡久久精品无码免费| 久久久亚洲欧洲日产国码是AV| 久久久久国产精品嫩草影院| 久久久久久无码国产精品中文字幕| 久久精品国产99国产精品| 伊人久久五月天| 久久99精品综合国产首页| 国产精品99久久久精品无码| 久久免费国产精品一区二区| 国产美女亚洲精品久久久综合| 久久人人爽人人爽人人片AV不 | 久久精品国产亚洲AV蜜臀色欲| 无码人妻久久一区二区三区| 精品久久久久久久久久中文字幕 | 国产综合久久久久| 色婷婷噜噜久久国产精品12p| 国产成人精品久久免费动漫| 国产精品99久久久久久宅男小说 | 国产精品久久永久免费| 久久久久久国产a免费观看黄色大片| 久久久久人妻精品一区二区三区 | 欧美午夜A∨大片久久| 久久久久国产精品熟女影院| 久久精品国产亚洲av麻豆图片| 久久一本综合| 久久久久国产精品麻豆AR影院 | 国产亚洲精品美女久久久| 国产精品久久久香蕉| 久久伊人五月天论坛| 欧美日韩成人精品久久久免费看| 欧美精品一本久久男人的天堂| 久久国产免费直播|