Linux下，產生core檔案，和不產生core檔案的條件：

當我們的程式崩潰時，核心有可能把該程式當前記憶體對映到core檔案裡，方便程式設計師找到程式出現問題的地方。最常出現的，幾乎所有C程式設計師都出現過的錯誤就是“段錯誤”了。也是最難查出問題原因的一個錯誤。下面我們就針對“段錯誤”來分析core檔案的產生、以及我們如何利用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*/

1 #include <stdio.h>

2

3 const char *str = “test”;

4

5 void core_test()

6 {

7     str[1] = ‘T’;

8 }

9

10 int main()

11 {

12     core_test();

13

14     return 0;

15 }

編譯：

[[email protected] core_dump]$ gcc –g core_dump_test.c -o core_dump_test

如果需要除錯程式的話，使用gcc編譯時加上-g選項，這樣除錯core檔案的時候比較容易找到錯誤的地方。

執行：

[[email protected] core_dump]$ ./core_dump_test

段錯誤

執行core_dump_test程式出現了“段錯誤”，但沒有產生core檔案。這是因為系統預設core檔案的大小為0，所以沒有建立。可以用ulimit命令檢視和修改core檔案的大小。

[[email protected] core_dump]$ ulimit -c

0

[[email protected] core_dump]$ ulimit -c 1000

[[email protected] core_dump]$ ulimit -c

1000

-c 指定修改core檔案的大小，1000指定了core檔案大小。也可以對core檔案的大小不做限制，如：

[[email protected] daemon]# ulimit -c unlimited

[[email protected] daemon]# ulimit -c

unlimited

如果想讓修改永久生效，則需要修改配置檔案，如 .bash_profile、/etc/profile或/etc/security/limits.conf。

再次執行：

[[email protected] core_dump]$ ./core_dump_test

段錯誤 (core dumped)

[[email protected] core_dump]$ ls core.*

core.6133

可以看到已經建立了一個core.6133的檔案.6133是core_dump_test程式執行的程序ID。

調式core檔案

core檔案是個二進位制檔案，需要用相應的工具來分析程式崩潰時的記憶體映像。

[[email protected] core_dump]$ 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檔案。

[[email protected] core_dump]$ gdb core_dump_test core.6133

GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)

Copyright 2003 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type “show copying” to see the conditions.

There is absolutely no warranty for GDB.  Type “show warranty” for details.

This GDB was configured as “i386-redhat-linux-gnu”…

Core was generated by `./core_dump_test’.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /lib/tls/libc.so.6…done.

Loaded symbols for /lib/tls/libc.so.6

Reading symbols from /lib/ld-linux.so.2…done.

Loaded symbols for /lib/ld-linux.so.2

#0  0×080482fd in core_test () at core_dump_test.c:7

7           str[1] = ‘T’;

(gdb) where

#0  0×080482fd in core_test () at core_dump_test.c:7

#1  0×08048317 in main () at core_dump_test.c:12

#2  0×42015574 in __libc_start_main () from /lib/tls/libc.so.6

GDB中鍵入where，就會看到程式崩潰時堆疊資訊（當前函式之前的所有已呼叫函式的列表（包括當前函式），gdb只顯示最近幾個），我們很容易找到我們的程式在最後崩潰的時候呼叫了core_dump_test.c 第7行的程式碼，導致程式崩潰。注意：在編譯程式的時候要加入選項-g。您也可以試試其他命令，　如　fram、list等。更詳細的用法，請查閱GDB文件。

core檔案建立在什麼位置

在程序當前工作目錄的下建立。通常與程式在相同的路徑下。但如果程式中呼叫了chdir函式，則有可能改變了當前工作目錄。這時core檔案建立在chdir指定的路徑下。有好多程式崩潰了，我們卻找不到core檔案放在什麼位置。和chdir函式就有關係。當然程式崩潰了不一定都產生core檔案。

什麼時候不產生core檔案

在下列條件下不產生core檔案：

( a )程序是設定-使用者-ID，而且當前使用者並非程式檔案的所有者；

( b )程序是設定-組-ID，而且當前使用者並非該程式檔案的組所有者；

a，b可以通過設定/proc/sys/kernel/suid_dumpable來改變，這樣suid的也可以產生core檔案

( c )使用者沒有寫當前工作目錄的許可權；

( d )檔案太大。core檔案的許可權(假定該檔案在此之前並不存在)通常是使用者讀/寫，組讀和其他讀。

利用GDB除錯core檔案，當遇到程式崩潰時我們不再束手無策。