利用MAP文件精確定位代碼中出錯的代碼行

程序,我最擔心到的事情是什?是內存泄漏?是界面不好看?……啦!我相信我的看法是不會有人反——那就是,程序生了崩

程序行了非法操作,即將關閉與你的件供系。,呵呵, M$ 名言,恐怕就是程序最擔心到的西了。有的候,自己的程序在自己的機器上運行得好好的,但是到了人的機器上就崩了;有自己在寫和測試程中就莫名其妙地遇到了非法操作,但是卻無法確定到底是源代中的哪行引起的……是不是很痛苦呢?不要,本文可以幫助你走出這種困境,甚至你從此之後可以自豪地要求用把崩地址告你,然後你就可以精確地定位到源代中出的那行了。(很神奇吧?呵呵。)

首先我必須強調的是,本方法可以在目前市面上任意一款編譯器上面使用。但是我只熟悉 M$  VC  MASM ,因此後面的部分只介如何在兩個編譯器中實現請讀者自行融會通,掌握在編譯器上使用的方法。

 

首先必生成程序的 MAP 文件。什 MAP 文件?簡單 MAP 文件是程序的全局符號、源文件和代行號信息的唯一的文本表示方法,它可以在任何地方、任何候使用,不需要有外的程序行支持。而且,是唯一能找出程序崩的地方的救星。

們應該如何生成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”

 MASM 中,我編譯接參數,我通常是這樣做的:

rc %1.rc
ml /c /coff /Zd %1.asm
link /subsystem:windows /mapinfo:exports /mapinfo:lines /map:%1.map %1.obj %1.res 

把它保存成 makem.bat ,就可以在命令行 makem filename 編譯生成 EXE 行文件和 MAP 文件了。

在此我先解一下加入的參數的含

/Zd              
表示在編譯候生成行信息
/map[:filename]  
表示生成 MAP 文件的路徑和文件名
/mapinfo:lines   
表示生成 MAP 文件,加入行信息
/mapinfo:exports 
表示生成 MAP 文件,加入 exported functions (如果生成的是 DLL 文件,選項就要加上) 

OK
,通上面的步驟,我得到了 MAP 文件,那們該如何利用它呢?

簡單例入手,你的 VC ,新建這樣一個文件:

01  //****************************************************************
02  //
程序名稱:演示如何通
地址找出源代的出
03  //
作者:Eric

04  //
日期:2003-2-7
05  //
:Eric的空間

06  //本程序會0錯誤,以至於會非法操作對話框。
07  //“0錯誤只會在 Debug 版本下生,本程序了演示而儘量化。
08  //注意事:如欲轉載保持本程序的完整,並註明:
09  //
轉載“億人博覽
10  //****************************************************************
11  
12  void Crash(void)
13  {
14      int i = 1;
15      int j = 0;
16      i /= j;
17  }
18  
19  void main(void)
20  {
21      Crash();
22  } 

然本程序有0錯誤,在 Debug 方式下編譯,運行肯定會非法操作好,運行它,果然,非法操作對話框出了,這時詳細信息記錄生崩的地址——在我的機器上是 0x0040104a 

再看看它的 MAP 文件:(由於文件內容太,中沒用的部分我行了省略)

CrashDemo

Timestamp is 3e430a76 (Fri Feb 07 09:23:02 2003)

Preferred load address is 00400000

Start         Length     Name                   Class
0001:00000000 0000de04H .text                   CODE
0001:0000de04 0001000cH .textbss                CODE
0002:00000000 00001346H .rdata                  DATA
0002:00001346 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 00000b93H .data                   DATA
0003:000015c4 00001974H .bss                    DATA
0004:00000000 00000014H .idata$2                DATA
0004:00000014 00000014H .idata$3                DATA
0004:00000028 00000110H .idata$4                DATA
0004:00000138 00000110H .idata$5                DATA
0004:00000248 000004afH .idata$6                DATA

  Address         Publics by Value              Rva+Base     Lib:Object

0001:00000020       ?Crash@@YAXXZ              00401020 f   CrashDemo.obj
0001:00000070       _main                      00401070 f   CrashDemo.obj
0004:00000000       __IMPORT_DESCRIPTOR_KERNEL32 00424000     kernel32:KERNEL32.dll
0004:00000014       __NULL_IMPORT_DESCRIPTOR   00424014     kernel32:KERNEL32.dll
0004:00000138       __imp__GetCommandLineA@0   00424138     kernel32:KERNEL32.dll
0004:0000013c       __imp__GetVersion@0        0042413c     kernel32:KERNEL32.dll
0004:00000140       __imp__ExitProcess@4       00424140     kernel32:KERNEL32.dll
0004:00000144       __imp__DebugBreak@0        00424144     kernel32:KERNEL32.dll
0004:00000148       __imp__GetStdHandle@4      00424148     kernel32:KERNEL32.dll
0004:0000014c       __imp__WriteFile@20        0042414c     kernel32:KERNEL32.dll
0004:00000150       __imp__InterlockedDecrement@4 00424150     kernel32:KERNEL32.dll
0004:00000154       __imp__OutputDebugStringA@4 00424154     kernel32:KERNEL32.dll
0004:00000158       __imp__GetProcAddress@8    00424158     kernel32:KERNEL32.dll
0004:0000015c       __imp__LoadLibraryA@4      0042415c     kernel32:KERNEL32.dll
0004:00000160       __imp__InterlockedIncrement@4 00424160     kernel32:KERNEL32.dll
0004:00000164       __imp__GetModuleFileNameA@12 00424164     kernel32:KERNEL32.dll
0004:00000168       __imp__TerminateProcess@8  00424168     kernel32:KERNEL32.dll
0004:0000016c       __imp__GetCurrentProcess@0 0042416c     kernel32:KERNEL32.dll
0004:00000170       __imp__UnhandledExceptionFilter@4 00424170     kernel32:KERNEL32.dll
0004:00000174       __imp__FreeEnvironmentStringsA@4 00424174     kernel32:KERNEL32.dll
0004:00000178       __imp__FreeEnvironmentStringsW@4 00424178     kernel32:KERNEL32.dll
0004:0000017c       __imp__WideCharToMultiByte@32 0042417c     kernel32:KERNEL32.dll
0004:00000180       __imp__GetEnvironmentStrings@0 00424180     kernel32:KERNEL32.dll
0004:00000184       __imp__GetEnvironmentStringsW@0 00424184     kernel32:KERNEL32.dll
0004:00000188       __imp__SetHandleCount@4    00424188     kernel32:KERNEL32.dll
0004:0000018c       __imp__GetFileType@4       0042418c     kernel32:KERNEL32.dll
0004:00000190       __imp__GetStartupInfoA@4   00424190     kernel32:KERNEL32.dll
0004:00000194       __imp__HeapDestroy@4       00424194     kernel32:KERNEL32.dll
0004:00000198       __imp__HeapCreate@12       00424198     kernel32:KERNEL32.dll
0004:0000019c       __imp__HeapFree@12         0042419c     kernel32:KERNEL32.dll
0004:000001a0       __imp__VirtualFree@12      004241a0     kernel32:KERNEL32.dll
0004:000001a4       __imp__RtlUnwind@16        004241a4     kernel32:KERNEL32.dll
0004:000001a8       __imp__GetLastError@0      004241a8     kernel32:KERNEL32.dll
0004:000001ac       __imp__SetConsoleCtrlHandler@8 004241ac     kernel32:KERNEL32.dll
0004:000001b0       __imp__IsBadWritePtr@8     004241b0     kernel32:KERNEL32.dll
0004:000001b4       __imp__IsBadReadPtr@8      004241b4     kernel32:KERNEL32.dll
0004:000001b8       __imp__HeapValidate@12     004241b8     kernel32:KERNEL32.dll
0004:000001bc       __imp__GetCPInfo@8         004241bc     kernel32:KERNEL32.dll
0004:000001c0       __imp__GetACP@0            004241c0     kernel32:KERNEL32.dll
0004:000001c4       __imp__GetOEMCP@0          004241c4     kernel32:KERNEL32.dll
0004:000001c8       __imp__HeapAlloc@12        004241c8     kernel32:KERNEL32.dll
0004:000001cc       __imp__VirtualAlloc@16     004241cc     kernel32:KERNEL32.dll
0004:000001d0       __imp__HeapReAlloc@16      004241d0     kernel32:KERNEL32.dll
0004:000001d4       __imp__MultiByteToWideChar@24 004241d4     kernel32:KERNEL32.dll
0004:000001d8       __imp__LCMapStringA@24     004241d8     kernel32:KERNEL32.dll
0004:000001dc       __imp__LCMapStringW@24     004241dc     kernel32:KERNEL32.dll
0004:000001e0       __imp__GetStringTypeA@20   004241e0     kernel32:KERNEL32.dll
0004:000001e4       __imp__GetStringTypeW@16   004241e4     kernel32:KERNEL32.dll
0004:000001e8       __imp__SetFilePointer@16   004241e8     kernel32:KERNEL32.dll
0004:000001ec       __imp__SetStdHandle@8      004241ec     kernel32:KERNEL32.dll
0004:000001f0       __imp__FlushFileBuffers@4  004241f0     kernel32:KERNEL32.dll
0004:000001f4       __imp__CloseHandle@4       004241f4     kernel32:KERNEL32.dll
0004:000001f8       /177KERNEL32_NULL_THUNK_DATA 004241f8     kernel32:KERNEL32.dll

entry point at        0001:000000f0

Line numbers for ./Debug/CrashDemo.obj(d:/msdev/myprojects/crashdemo/crashdemo.cpp) segment .text

    13 0001:00000020    14 0001:00000038    15 0001:0000003f    16 0001:00000046
    17 0001:00000050    20 0001:00000070    21 0001:00000088    22 0001:0000008d 

如果仔
細瀏覽 Rva+Base 這欄,你會發現第一個比崩地址 0x0040104a 大的函數地址是 0x00401070 ,所以在 0x00401070 個地址之前的那個入口就是生崩的函數,也就是行:
0001:00000020       ?Crash@@YAXXZ              00401020 f   CrashDemo.obj 
因此,
生崩的函數就是 ?Crash@@YAXXZ ,所有以開頭的函數名稱都是 C++ 的名稱。在我的源程序中,也就是 Crash() 個子函數。

OK
在我們輕而易地便知道了生崩的函數名稱,你是不是很興奮呢?呵呵,先忙,接下來,更害的招數要出了。

注意 MAP 文件的最後部分——行信息(Line numbers information),它是以這樣的形式示的:

13 0001:00000020 

第一個數字代表在源代中的代行號,第二個數是行在所屬的代段中的偏移量。

如果要找代行號,需要使用下面的公式做一些十六制的減法運算:

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

這樣做呢?心的朋友可能會留意到 Rva+Base 這欄了,我得到的崩地址都是由 偏移地址(Rva基地址(Base 得來的,所以在算行號的候要把基地址減去,一般情況下,基地址的 0x00400000 。另外,由於一般的 PE 文件的代段都是從 0x1000 偏移始的,所以也必減去 0x1000 

好了,明白了點,我就可以來行小學減法算了:

行偏移 = 0x0040104a - 0x00400000 - 0x1000 = 0x4a 

如果瀏覽 MAP 文件的代行信息,會看到不超過計果,但卻最接近的數是 CrashDemo.cpp 文件中的:

16 0001:00000046 

也就是在源代中的第 16 行,來看看源代:

16      i /= j; 

哈!!!果然就是第 16 行啊!

興奮嗎?我也一 :)

方法已完了,從今以後,我就可以精確地定位到源代中的崩行,而且只要編譯器可以生成 MAP 文件(包括 VCMASMVBBCB Delphi……),本方法都是適用的。我們時常抱怨 M$ 品如何如何差,但其 M$ 是有意無意提供了很多有價的信息的,只是我往往不懂得怎利用而已……相信這樣一來,你就可以更從容地面非法操作提示了。你甚至可以要求用提供崩的地址,然後就可以坐在家中舒舒服服地找到出的那行,並行修正。

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

發佈了23 篇原創文章 · 獲贊 107 · 訪問量 51萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章