當我們的程序崩潰時,內核有可能把該程序當前內存映射到core文件裏,方便程序員找到程序出現問題的地方。最常出 現的,幾乎所有C程序員都出現過的錯誤就是“段錯誤”了。也是最難查出問題原因的一個錯誤。下面我們就針對“段錯誤”來分析core文件的產生、以及我們 如何利用core文件找到出現崩潰的地方。 當一個程序崩潰時,在進程當前工作目錄的core文件中複製了該進程的存儲圖像。core文件僅僅是一個內存映象(同時加上調試信息),主要是用來調試的。 當程序接收到以下UNIX信號會產生core文件:
在系統默認動作列,“終止w/core”表示在進程當前工作目錄的core文件中複製了該進程的存儲圖像(該文件名爲core,由此可以看出這種功能很久之前就是UNIX功能的一部分)。大多數UNIX調試程序都使用core文件以檢查進程在終止時的狀態。 core文件的產生不是POSIX.1所屬部分,而是很多UNIX版本的實現特徵。UNIX第6版沒有檢查條件 (a)和(b),並且其源代碼中包含如下說明:“如果你正在找尋保護信號,那麼當設置-用戶-ID命令執行時,將可能產生大量的這種信號”。4.3 + BSD產生名爲core.prog的文件,其中prog是被執行的程序名的前1 6個字符。它對core文件給予了某種標識,所以是一種改進特徵。 表中“硬件故障”對應於實現定義的硬件故障。這些名字中有很多取自UNIX早先在DP-11上的實現。請查看你所使用的系統的手冊,以確切地確定這些信號對應於哪些錯誤類型。 下面比較詳細地說明這些信號。 • SIGABRT 調用abort函數時產生此信號。進程異常終止。 • SIGBUS 指示一個實現定義的硬件故障。 • SIGEMT 指示一個實現定義的硬件故障。 EMT這一名字來自PDP-11的emulator trap 指令。 • SIGFPE 此信號表示一個算術運算異常,例如除以0,浮點溢出等。 • SIGILL 此信號指示進程已執行一條非法硬件指令。 4.3BSD由abort函數產生此信號。SIGABRT現在被用於此。 • SIGIOT 這指示一個實現定義的硬件故障。 IOT這個名字來自於PDP-11對於輸入/輸出TRAP(input/output TRAP)指令的縮寫。系統V的早期版本,由abort函數產生此信號。SIGABRT現在被用於此。 • SIGQUIT 當用戶在終端上按退出鍵(一般採用Ctrl-\)時,產生此信號,並送至前臺進 程組中的所有進程。此信號不僅終止前臺進程組(如SIGINT所做的那樣),同時產生一個core文件。 • SIGSEGV 指示進程進行了一次無效的存儲訪問。 名字SEGV表示“段違例(segmentation violation)”。 • SIGSYS 指示一個無效的系統調用。由於某種未知原因,進程執行了一條系統調用指令, 但其指示系統調用類型的參數卻是無效的。 • SIGTRAP 指示一個實現定義的硬件故障。 此信號名來自於PDP-11的TRAP指令。 • SIGXCPU SVR4和4.3+BSD支持資源限制的概念。如果進程超過了其軟C P U時間限制,則產生此信號。 • SIGXFSZ 如果進程超過了其軟文件長度限制,則SVR4和4.3+BSD產生此信號。 摘自《UNIX環境高級編程》第10章 信號。
使用core文件調試程序 看下面的例子:
/*core_dump_test.c*/
編譯: 如果需要調試程序的話,使用gcc編譯時加上-g選項,這樣調試core文件的時候比較容易找到錯誤的地方。
執行:
運行core_dump_test程序出現了“段錯誤”,但沒有產生core文件。這是因爲系統默認core文件的大小爲0,所以沒有創建。可以用ulimit命令查看和修改core文件的大小。 -c 指定修改core文件的大小,1000指定了core文件大小。也可以對core文件的大小不做限制,如:
ulimit -c unlimited 如果想讓修改永久生效,則需要修改配置文件,如 .bash_profile、/etc/profile或/etc/security/limits.conf。
再次執行: 可以看到已經創建了一個core.6133的文件.6133是core_dump_test程序運行的進程ID。
調式core文件 file core.6133 core.6133: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'core_dump_test' 在Linux下可以用GDB來調試core文件。 gdb core_dump_test core.6133
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) GDB中鍵入where,就會看到程序崩潰時堆棧信息(當前函數之前的所有已調用函數的列表(包括當前函數),gdb只顯示最近幾個),我們很容易找到我們的程序在最後崩潰的時候調用了core_dump_test.c 第7行的代碼,導致程序崩潰。注意:在編譯程序的時候要加入選項-g。您也可以試試其他命令, 如 fram、list等。更詳細的用法,請查閱GDB文檔。 core文件創建在什麼位置 在進程當前工作目錄的下創建。通常與程序在相同的路徑下。但如果程序中調用了chdir函數,則有可能改變了當前工 作目錄。這時core文件創建在chdir指定的路徑下。有好多程序崩潰了,我們卻找不到core文件放在什麼位置。和chdir函數就有關係。當然程序 崩潰了不一定都產生core文件。
在下列條件下不產生core文件: 利用GDB調試core文件,當遇到程序崩潰時我們不再束手無策。 |
linux下的core 文件
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.