ubuntu core 檔案產生

標籤：style   http   color   io   os   使用   ar   strong   檔案   

關於核心轉儲的設定方法

 

1. 核心轉儲作用

 

(1) 核心轉儲的最大好處是能夠儲存問題發生時的狀態。

(2) 只要有可執行檔和核心轉儲，就可以知道進程當時的狀態。

(3) 只要擷取核心轉儲，那麼即使沒有複現環境，也能調試。

 

2. 啟用核心轉儲

1.1 查看核心轉儲是否有效

在終端中輸入以下命令，查看核心轉儲是否有效。

#ulimit -c

0

-c 表示核心轉儲檔案的大小限制，現在顯示為零，表示不能用。

可以改為1G

#ulimit -c 1073741824

也可以改為無限制

#ulimit -c unlimited

 

2.2 測試一個例子

例子的原始碼：

#include <stdio.h>

int main(void)

{

int *a = NULL;

*a = 0x1;

return 0;

}

 

把以上原始碼，寫成一個a.c檔案後，編譯a.c檔案產生一個a.out的可執行檔：

#gcc -g a.c -o a.out

修改a.out檔案的許可權後，執行它：

#./a.out

就會顯示：

Segmentation fault(core dump)

這表示在目前的目錄下, 已經產生了a.out對應的核心轉儲檔案。

注意：後面帶有(core dump), 才說明轉儲檔案成功產生了。

#file core*

core:ELF 64-bit LSB core file x86-64, version 1(SYSV), SVR4-style, from ‘./a.out‘

coreDump: UTF-8 Unicode C program text

 

要用GDB調試核心轉儲檔案，應該使用以下方式啟動GDB:

#gdb -c ./*.core ./a.out

GNU gdb (GDB) 7.1-Ubuntu

...

Core was generated by ‘./a.out‘.

Program terminated with signal 11, Segmentation fault.

#0 0x00000000004004dc in main() at a.c:6

6 *a =0x1;

a.c的第6行收到了11號訊號。用GDB的list命令可以查看附近的原始碼。

(gdb) l 5

1            #include <stdio.h>

2           

3            int main(void)

4            {

5                   int *a = NULL;

6                   *a = 0x1;

7                   return 0;

8            }

這裡預設都是目前的目錄，也可以給core 和a.out 指定路徑

到這裡測試完成！

 

2.3 永久生效的辦法

上面所述的方法，只是在當前shell中生效,重啟之後，就不再有效了。永久生效的辦法是：

#vi /etc/profile 然後，在profile中添加：

ulimit -c 1073741824

 (但是，若將產生的轉儲檔案大小大於該數字時，將不會產生轉儲檔案)

或者

ulimit -c unlimited

 

這樣重啟機器後生效了。 或者， 使用source命令使之馬上生效。

#source /etc/profile

 

3. 指定核心轉儲的檔案名稱和目錄

預設情況下，核心在coredump時所產生的core檔案放在與該程式相同的目錄中，並且檔案名稱固定為core。很顯然，如果有多個程式產生core檔案，或者同一個程式多次崩潰，就會重複覆蓋同一個core檔案。

我們可以通過修改kernel的參數，指定核心轉儲所產生的core檔案的路徑和檔案名稱。

可以通過在/etc/sysctl.conf檔案中，對sysctl變數kernel.core_pattern的設定。

#vi /etc/sysctl.conf 然後，在sysctl.conf檔案中添加下面兩句話：

kernel.core_pattern = /var/core/core_%e_%p

kernel.core_uses_pid = 0

儲存後退出。

需要說明的是， /proc/sys/kernel/core_uses_pid。如果這個檔案的內容被配置成1，即使core_pattern中沒有設定%p，最後產生的core dump檔案名稱仍會加上進程ID。

這裡%e, %p分別表示：

%c 轉儲檔案的大小上限

%e 所dump的檔案名稱

%g 所dump的進程的實際組ID

%h 主機名稱

%p 所dump的進程PID

%s 導致本次coredump的訊號

%t 轉儲時刻(由1970年1月1日起計的秒數)

%u 所dump進程的實際使用者ID

可以使用以下命令，使修改結果馬上生效。

#sysctl –p /etc/sysctl.conf

 

請在/var目錄下先建立core檔案夾，然後執行a.out程式，就會在/var/core/下產生以指定格式命名的核心轉儲檔案。查看轉儲檔案的情況：

#ls /var/core

core_a.out_2834

 

4. 手動強制某個進程產生core dump的方法（嘗試）

當某些程式發生crash時，對應進程會產生coredump檔案。通過這個coredump檔案，開發人員可以找到bug的原因。但是coredump的產生，大都是因為程式crash了。

而有些bug是不會導致程式crash的，比如死結，這時程式已經不正常了，可是卻沒有coredump產生。如果環境又不允許gdb調試，難道我們就束手無策了嗎？

針對以上這種情況，一般情況下，對於這樣的進程可以利用 watchdog監控它們，當發現這些進程很長時間沒有更新其heartbeat時，可以給這些進程發送可以導致其產生coredump的訊號。根據 linux的訊號預設的處理行為，SIGQUIT，SIGABRT, SIGFPE和SIGSEGV都可以讓該進程產生coredump檔案。這樣我們可以通過coredump來得知死結是否發生。 當然， 如果進程添加了這些訊號的處理函數，那麼就不會產生coredump了。不過，對於SIGQUIT, SIGABRT, SIGFPE, SIGSEGV，有誰會為它們加上訊號處理函數呢。

 

還有一種情況，進程並沒有死結或者block在某個位置， 但是我們需要在某個指定位置進行調試，擷取某些變數或者其它資訊。但是，有可能是客戶環境或者生產環境，不允許我們進行長時間的檢測。那麼，我們就需要通 過coredump來獲得進程在運行到該點時的快照。 這個時候，可以利用gdb來手工產生coredump。在attach上這個進程時，在指定位置打上斷點，當斷點觸發時，使用gdb的命令gcore，可 以立即產生一個coredump。 這樣，我們就拿到了這個位置的進程快照。

 

1．尋找您要發送訊號的進程ID，

 

# ps -ef  | grep qemu

root      3207  3206 44 10:32 pts/1    00:00:18 /usr/local/bin/qemu-system-x86

得出 qemu-system-x86的 PID號是3207

2．使用kill(1)去發送訊號。

 

# /bin/kill -s QUIT 3207

 

發送其他的訊號也很相似， 只要在命令列中替換QUIT 為ABRT，TERM 或 KILL 就行了

 

重要提示: 在系統上隨意殺死進程是一個壞主意，特別是init(8)，它的PID是1，它非常特殊。 可以運行 /bin/kill -s KILL 1 命令來讓系統迅速關機。  當您按下 Return （斷行符號）鍵之前，一定要 詳細檢查您運行 kill(1) 時所指定的參數。

 

5 使用core dump進行調試

在Linux下遇到“段錯誤”(segmentation fault)，如果段錯誤發生在伺服器端，而伺服器端要繼續工作，不允許調試，這時“核心轉儲(core dump)”就派上了用場，可以把產生的核心轉儲複製到本地進行調試。

    首先，按照上面的永久生效方法，在伺服器上進行相應設定。 然後程式在崩潰時，就會在程式所在目錄（或自己指定的目錄）產生一個core檔案，把這個core檔案拷到本地(最好與該進程對應的可執行檔放到同一個目錄，若不然，在gdb時指出路徑也可以)。

 

具體方法如下：

方法一：

輸入命令 #gdb <程式可執行檔> <coredump轉儲檔案>

例如：

# gdb /usr/local/bin/qemu-system-x86_64  /var/core/core-3207-qemu-system-x86

然後，在(gdb)提示符後輸入 l,  會顯示main主函數

 

 

方法二：

(1) 在終端輸入命令# gdb [-c] <coredump檔案>，

例如： gdb -c /var/core/core-3207-qemu-system-x86

(2)然後，在(gdb)提示符後輸入file <可執行程式>

例如：(gdb) file  /usr/local/bin/qemu-system-x86_64

(3) 這時就可以用backtrace/thread等命令查看當時的錯誤了，就像程式在本地執行到崩潰點一樣

或者用where斷行符號, 也可以顯示程式在哪一行當掉的

 

5. 啟用整個系統的核心轉儲

(未完待續......)

 

(4.1) 編輯/etc/profile, 開啟登入到系統的所有使用者的核心轉儲功能

首先，看看用的是個什麼機器：

# uname –a

Linux ubuntu240 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 2010 x86_64 GNU/Linux

其次，再查看一些預設參數，若core file size是0，即使程式出錯時，也不會產生core檔案。

# ulimit -a

core file size              (blocks, -c) unlimited

data seg size              (kbytes, -d) unlimited

scheduling priority               (-e) 20

file size                  (blocks, -f) unlimited

pending signals                  (-i) 16382

max locked memory        (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size              (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority                (-r) 0

stack size                (kbytes, -s) 8192

cpu time                (seconds, -t) unlimited

max user processes              (-u) unlimited

virtual memory           (kbytes, -v) unlimited

file locks                      (-x) unlimited

 

ubuntu core 檔案產生