僅通過崩潰地址找出原始碼的出錯行 (11千字)

看雪資料發表於2003-02-07

作為程式設計師,我們平時最擔心見到的事情是什麼?是記憶體洩漏?是介面不好看?……錯啦!我相信我的看法是不會有人反對的――那就是,程式發生了崩潰!

“該程式執行了非法操作,即將關閉。請與你的軟體供應商聯絡。”,呵呵,這句 M$ 的“名言”,恐怕就是程式設計師最擔心見到的東西了。有的時候,自己的程式在自己的機器上執行得好好的,但是到了別人的機器上就崩潰了;有時自己在編寫和測試的過程中就莫名其妙地遇到了非法操作,但是卻無法確定到底是原始碼中的哪行引起的……是不是很痛苦呢?不要緊,本文可以幫助你走出這種困境,甚至你從此之後可以自豪地要求使用者把崩潰地址告訴你,然後你就可以精確地定位到原始碼中出錯的那行了。(很神奇吧?呵呵。)

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

Well,廢話說完了,讓我們開始! :)

首先必須生成程式的 MAP 檔案。什麼是 MAP 檔案?簡單地講, MAP 檔案是程式的全域性符號、原始檔和程式碼行號資訊的唯一的文字表示方法,它可以在任何地方、任何時候使用,不需要有額外的程式進行支援。而且,這是唯一能找出程式崩潰的地方的救星。

好吧,既然 MAP 檔案如此神奇,那麼我們應該如何生成它呢?在 VC 中,我們可以按下 Alt+F7 ,開啟“Project Settings”選項頁,選擇 C/C++ 選項卡,並在最下面的 Project Options 裡面輸入:/Zd ,然後要選擇 Link 選項卡,在最下面的 Project Options 裡面輸入: /mapinfo:lines 和 /map:PROJECT_NAME.map 。最後按下 F7 來編譯生成 EXE 可執行檔案和 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  //作者:羅聰
04  //日期:2003-2-7
05  //出處:http://www.luocong.com(老羅的繽紛天地)
06  //本程式會產生“除0錯誤”,以至於會彈出“非法操作”對話方塊。
07  //“除0錯誤”只會在 Debug 版本下產生,本程式為了演示而儘量簡化。
08  //注意事項:如欲轉載,請保持本程式的完整,並註明:
09  //轉載自“老羅的繽紛天地”(http://www.luocong.com)
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 檔案(包括 VC、MASM、VB、BCB、Delphi……),本方法都是適用的。我們時常抱怨 M$ 的產品如何如何差,但其實 M$ 還是有意無意間提供了很多有價值的資訊給我們的,只是我們往往不懂得怎麼利用而已……相信這樣一來,你就可以更為從容地面對“非法操作”提示了。你甚至可以要求使用者提供崩潰的地址,然後就可以坐在家中舒舒服服地找到出錯的那行,並進行修正。

是不是很爽呢? :) 
 
                                            老羅
                                            2003-2-7

相關文章