使用MAP文件 尋找程序崩潰原因

重要參考網址:
VS編譯器 編譯選擇項說明

自動崩潰轉儲

一般程序崩潰可以通過debug,找到程序在那一行代碼崩潰了,最近編一個多線程的程序,都不知道在那發生錯誤,多線程併發,又不好單行調試,終於找到一個比較好的方法來找原因,通過生成map文件,由於2005取消map文件生成行號信息(vc6.0下是可以生成行號信息的,不知道microsoft怎麼想的,在2005上取消了),只能定位在那個函數發生崩潰。這裏可以通過生成cod文件,即機器碼這一文件,具體定位在那一行崩潰。 

首先配置vc2005生成map文件和cod文件: 
(1).map文件:property->Configuration Properties->Linker->Debugging 中的Generate Map File選擇Yes(/MAP); 

(2).cod文件:property->Configuration Properties->C/C++->output Files中Assembler OutPut中選擇Assembly,Maching Code and Source(/FAcs),生成機器,源代碼。 

上面所說的 property 是“項目”菜單下的 property,而非“工具”菜單下的 property。(轉者注) 

簡單例子:

C++代碼 複製代碼
  1. #include "stdafx.h"   
  2.   
  3. void errorFun(int * p)   
  4. {   
  5.  *p=1;   
  6. }   
  7.   
  8. int _tmain(int argc, _TCHAR* argv[])   
  9. {   
  10.  int * p=NULL;   
  11.  errorFun(p);   
  12.  return 0;   
  13. }  

在errorFun中函數中,*p=1這一行出錯,由於p沒有申請空間,運行時出錯,彈出 
Unhandled exception at 0x004113b1 in testError.exe: 0xC0000005: Access violation writing location 0x00000000. 
在0x004113b1程序發生崩潰。 

具體步驟: 
(1)debug文件下打開map文件,定位崩潰函數. 

map文件開頭是一些鏈接信息,然後我們要找函數和實始地址信息。地址是函始的開始地址 

Address       Publics by Value       Rva+Base    Lib:Object 

0000:00000000    ___safe_se_handler_count   00000000    <absolute> 
0000:00000000    ___safe_se_handler_table   00000000    <absolute> 
0000:00000000    ___ImageBase         00400000    <linker-defined> 
0001:00000000    __enc$textbss$begin      00401000     <linker-defined> 
0001:00010000    __enc$textbss$end       00411000     <linker-defined> 
0002:00000390    ?errorFun@@YAXPAH@Z    00411390 f    testError.obj 
0002:000003d0    _wmain            004113d0 f    testError.obj 
0002:00000430    __RTC_InitBase        00411430 f   MSVCRTD:init.obj 
0002:00000470    __RTC_Shutdown        00411470 f   MSVCRTD:init.obj 
0002:00000490    __RTC_CheckEsp        00411490 f   MSVCRTD:stack.obj 
0002:000004c0    @_RTC_CheckStackVars@8    004114c0 f   MSVCRTD:stack.obj 
0002:00000540    @_RTC_AllocaHelper@12     00411540 f    MSVCRTD:stack.obj 

.... 

程序崩潰地址0x004113b1,我們找到第一個比這個地址大的004113d0,前一個是00411390,地址是函數的開始地址,所以發生的崩潰的的函數是errorFun,這個函數的初始地址00411390. 

(2)找出具體崩潰行號. 

由(2)可知,發生錯誤函數是errorFun,在testError.obj,打開testError.cod文件,找到errorFun函數生成的機器碼. 

?errorFun@@YAXPAH@Z PROC    ; errorFun, COMDAT 

; 7    : { 

  00000 55   push  ebp 
  00001 8b ec   mov  ebp, esp 
  00003 81 ec c0 00 00 
00   sub  esp, 192  ; 000000c0H 
  00009 53   push  ebx 
  0000a 56   push  esi 
  0000b 57   push  edi 
  0000c 8d bd 40 ff ff 
ff   lea  edi, DWORD PTR [ebp-192] 
  00012 b9 30 00 00 00  mov  ecx, 48   ; 00000030H 
  00017 b8 cc cc cc cc  mov  eax, -858993460  ; ccccccccH 
  0001c f3 ab   rep stosd 

; 8    :  *p=1; 

  0001e 8b 45 08  mov  eax, DWORD PTR _p$[ebp] 
  00021 c7 00 01 00 00 
00   mov  DWORD PTR [eax], 1 

; 9    : } 

  00027 5f   pop  edi 
  00028 5e   pop  esi 
  00029 5b   pop  ebx 
  0002a 8b e5   mov  esp, ebp 
  0002c 5d   pop  ebp 
  0002d c3   ret  0 
(說明: 7,8,9是表示在源代碼的行號。 
00000 55   push  ebp,000000是相對偏移地地,55是機器碼號,push ebp,000000是彙編碼。) 

通過(2)我們計算相對偏移地址,即崩潰地址-函數起始地址,0x004113b1-0x00411390=0x21(16進制的計數)。找到0x21這一行對應的機器碼是 00021 c7 00 01 00 00,向上看它是由第8行*p=1;生成的彙編碼,由此可見是這一行程序發生崩潰。 


結束語:當然這只是一個簡單的例子,實際上一運行便知道是這一行出錯,但是對於一個比較大的工程,特別是在多線程併發情況下,要找出那一行出錯比較困難,便可以使用map和cod文件找到程序崩潰原因。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章