如何理解coredump

本篇文章給大家分享的是有關如何理解coredump，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

一，什么是coredump

        我們經常聽到大家說到程序core掉了，需要定位解決，這里說的大部分是指對應程序由于各種異常或者bug導致在運行過程中異常退出或者中止，并且在滿足一定條件下（這里為什么說需要滿足一定的條件呢？下面會分析）會產生一個叫做core的文件。

        通常情況下，core文件會包含了程序運行時的內存，寄存器狀態，堆棧指針，內存管理信息還有各種函數調用堆棧信息等，我們可以理解為是程序工作當前狀態存儲生成第一個文件，許多的程序出錯的時候都會產生一個core文件，通過工具分析這個文件，我們可以定位到程序異常退出的時候對應的堆棧調用等信息，找出問題所在并進行及時解決。

二，coredump文件的存儲位置

   core文件默認的存儲位置與對應的可執行程序在同一目錄下，文件名是core，大家可以通過下面的命令看到core文件的存在位置：

   cat  /proc/sys/kernel/core_pattern

   缺省值是core

注意：這里是指在進程當前工作目錄的下創建。通常與程序在相同的路徑下。但如果程序中調用了chdir函數，則有可能改變了當前工作目錄。這時core文件創建在chdir指定的路徑下。有好多程序崩潰了，我們卻找不到core文件放在什么位置。和chdir函數就有關系。當然程序崩潰了不一定都產生 core文件。

如下程序代碼：則會把生成的core文件存儲在/data/coredump/wd，而不是大家認為的跟可執行文件在同一目錄。

通過下面的命令可以更改coredump文件的存儲位置，若你希望把core文件生成到/data/coredump/core目錄下：

   echo “/data/coredump/core”> /proc/sys/kernel/core_pattern

注意，這里當前用戶必須具有對/proc/sys/kernel/core_pattern的寫權限。

缺省情況下，內核在coredump時所產生的core文件放在與該程序相同的目錄中，并且文件名固定為core。很顯然，如果有多個程序產生core文件，或者同一個程序多次崩潰，就會重復覆蓋同一個core文件，因此我們有必要對不同程序生成的core文件進行分別命名。

我們通過修改kernel的參數，可以指定內核所生成的coredump文件的文件名。例如，使用下面的命令使kernel生成名字為core.filename.pid格式的core dump文件：

echo “/data/coredump/core.%e.%p” >/proc/sys/kernel/core_pattern

這樣配置后，產生的core文件中將帶有崩潰的程序名、以及它的進程ID。上面的%e和%p會被替換成程序文件名以及進程ID。

如果在上述文件名中包含目錄分隔符“/”，那么所生成的core文件將會被放到指定的目錄中。 需要說明的是，在內核中還有一個與coredump相關的設置，就是/proc/sys/kernel/core_uses_pid。如果這個文件的內容被配置成1，那么即使core_pattern中沒有設置%p，最后生成的core dump文件名仍會加上進程ID。

三，如何判斷一個文件是coredump文件？

在類unix系統下，coredump文件本身主要的格式也是ELF格式，因此，我們可以通過readelf命令進行判斷。

     可以看到ELF文件頭的Type字段的類型是：CORE (Core file)

     可以通過簡單的file命令進行快速判斷：     

四，產生coredum的一些條件總結

1，  產生coredump的條件，首先需要確認當前會話的ulimit –c，若為0，則不會產生對應的coredump，需要進行修改和設置。

ulimit  -c unlimited  (可以產生coredump且不受大小限制)

若想甚至對應的字符大小，則可以指定：

ulimit –c [size]

       可以看出，這里的size的單位是blocks,一般1block=512bytes

        如：

        ulimit –c 4  (注意，這里的size如果太小，則可能不會產生對應的core文件，筆者設置過ulimit –c 1的時候，系統并不生成core文件，并嘗試了1，2，3均無法產生core，至少需要4才生成core文件)

但當前設置的ulimit只對當前會話有效，若想系統均有效，則需要進行如下設置：

?  在/etc/profile中加入以下一行，這將允許生成coredump文件

ulimit-c unlimited

?  在rc.local中加入以下一行，這將使程序崩潰時生成的coredump文件位于/data/coredump/目錄下:

echo /data/coredump/core.%e.%p> /proc/sys/kernel/core_pattern 

注意rc.local在不同的環境，存儲的目錄可能不同，susu下可能在/etc/rc.d/rc.local

      更多ulimit的命令使用，可以參考：http://baike.baidu.com/view/4832100.htm

      這些需要有root權限, 在ubuntu下每次重新打開中斷都需要重新輸入上面的ulimit命令, 來設置core大小為無限.

2， 當前用戶，即執行對應程序的用戶具有對寫入core目錄的寫權限以及有足夠的空間。

3， 幾種不會產生core文件的情況說明：

The core file will not be generated if

(a)    the process was set-user-ID and the current user is not the owner of the program file, or

(b)     the process was set-group-ID and the current user is not the group owner of the file,

(c)     the user does not have permission to write in the current working directory, 

(d)     the file already exists and the user does not have permission to write to it, or 

(e)     the file is too big (recall the RLIMIT_CORE limit in Section 7.11). The permissions of the core file (assuming that the file doesn't already exist) are usually user-read and user-write, although Mac OS X sets only user-read.

五，coredump產生的幾種可能情況

造成程序coredump的原因有很多，這里總結一些比較常用的經驗吧：

 1，內存訪問越界

  a) 由于使用錯誤的下標，導致數組訪問越界。

  b) 搜索字符串時，依靠字符串結束符來判斷字符串是否結束，但是字符串沒有正常的使用結束符。

  c) 使用strcpy, strcat, sprintf, strcmp,strcasecmp等字符串操作函數，將目標字符串讀/寫爆。應該使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函數防止讀寫越界。

 2，多線程程序使用了線程不安全的函數。

應該使用下面這些可重入的函數，它們很容易被用錯：

asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n)ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c)getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c)fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c)getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3)getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n)nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3)getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c)getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c)getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)

 3，多線程讀寫的數據未加鎖保護。

對于會被多個線程同時訪問的全局數據，應該注意加鎖保護，否則很容易造成coredump

 4，非法指針

  a) 使用空指針

  b) 隨意使用指針轉換。一個指向一段內存的指針，除非確定這段內存原先就分配為某種結構或類型，或者這種結構或類型的數組，否則不要將它轉換為這種結構或類型的指針，而應該將這段內存拷貝到一個這種結構或類型中，再訪問這個結構或類型。這是因為如果這段內存的開始地址不是按照這種結構或類型對齊的，那么訪問它時就很容易因為bus error而core dump。

 5，堆棧溢出

不要使用大的局部變量（因為局部變量都分配在棧上），這樣容易造成堆棧溢出，破壞系統的棧和堆結構，導致出現莫名其妙的錯誤。  

六，利用gdb進行coredump的定位

  其實分析coredump的工具有很多，現在大部分類unix系統都提供了分析coredump文件的工具，不過，我們經常用到的工具是gdb。

  這里我們以程序為例子來說明如何進行定位。

1，  段錯誤 – segmentfault

?  我們寫一段代碼往受到系統保護的地址寫內容。

?  按如下方式進行編譯和執行，注意這里需要-g選項編譯。

可以看到，當輸入12的時候，系統提示段錯誤并且core dumped

?  我們進入對應的core文件生成目錄，優先確認是否core文件格式并啟用gdb進行調試。

從紅色方框截圖可以看到，程序中止是因為信號11，且從bt(backtrace)命令（或者where）可以看到函數的調用棧，即程序執行到coremain.cpp的第5行，且里面調用scanf 函數，而該函數其實內部會調用_IO_vfscanf_internal()函數。

接下來我們繼續用gdb，進行調試對應的程序。

記住幾個常用的gdb命令：

l(list) ，顯示源代碼，并且可以看到對應的行號；

b(break)x, x是行號，表示在對應的行號位置設置斷點；

p(print)x, x是變量名，表示打印變量x的值

r(run), 表示繼續執行到斷點的位置

n(next),表示執行下一步

c(continue),表示繼續執行

q(quit)，表示退出gdb

啟動gdb,注意該程序編譯需要-g選項進行。

注：  SIGSEGV     11       Core    Invalid memoryreference

七，附注：

1，  gdb的查看源碼

顯示源代碼

GDB 可以打印出所調試程序的源代碼，當然，在程序編譯時一定要加上-g的參數，把源程序信息編譯到執行文件中。不然就看不到源程序了。當程序停下來以后，GDB會報告程序停在了那個文件的第幾行上。你可以用list命令來打印程序的源代碼。還是來看一看查看源代碼的GDB命令吧。

list<linenum>

顯示程序第linenum行的周圍的源程序。

list<function>

顯示函數名為function的函數的源程序。

list

顯示當前行后面的源程序。

list -

顯示當前行前面的源程序。

一般是打印當前行的上5行和下5行，如果顯示函數是是上2行下8行，默認是10行，當然，你也可以定制顯示的范圍，使用下面命令可以設置一次顯示源程序的行數。

setlistsize <count>

設置一次顯示源代碼的行數。

showlistsize

查看當前listsize的設置。

list命令還有下面的用法：

list<first>, <last>

顯示從first行到last行之間的源代碼。

list ,<last>

顯示從當前行到last行之間的源代碼。

list +

往后顯示源代碼。

一般來說在list后面可以跟以下這些參數：

<linenum>   行號。

<+offset>   當前行號的正偏移量。

<-offset>   當前行號的負偏移量。

<filename:linenum>  哪個文件的哪一行。

<function>  函數名。

<filename:function>哪個文件中的哪個函數。

<*address>  程序運行時的語句在內存中的地址。

2，  一些常用signal的含義

SIGABRT：調用abort函數時產生此信號。進程異常終止。

SIGBUS：指示一個實現定義的硬件故障。

SIGEMT：指示一個實現定義的硬件故障。EMT這一名字來自PDP-11的emulator trap 指令。

SIGFPE：此信號表示一個算術運算異常，例如除以0，浮點溢出等。

SIGILL：此信號指示進程已執行一條非法硬件指令。4.3BSD由abort函數產生此信號。SIGABRT現在被用于此。

SIGIOT：這指示一個實現定義的硬件故障。IOT這個名字來自于PDP-11對于輸入／輸出TRAP(input/outputTRAP)指令的縮寫。系統V的早期版本，由abort函數產生此信號。SIGABRT現在被用于此。

SIGQUIT：當用戶在終端上按退出鍵（一般采用Ctrl-/）時，產生此信號，并送至前臺進

程組中的所有進程。此信號不僅終止前臺進程組（如SIGINT所做的那樣），同時產生一個core文件。

SIGSEGV：指示進程進行了一次無效的存儲訪問。名字SEGV表示“段違例（segmentationviolation）”。

SIGSYS：指示一個無效的系統調用。由于某種未知原因，進程執行了一條系統調用指令，但其指示系統調用類型的參數卻是無效的。

SIGTRAP：指示一個實現定義的硬件故障。此信號名來自于PDP-11的TRAP指令。

SIGXCPUSVR4和4.3+BSD支持資源限制的概念。如果進程超過了其軟C P U時間限制，則產生此信號。

SIGXFSZ：如果進程超過了其軟文件長度限制，則SVR4和4.3+BSD產生此信號。

3，  Core_pattern的格式

可以在core_pattern模板中使用變量還很多，見下面的列表：

%% 單個%字符

%p 所dump進程的進程ID

%u 所dump進程的實際用戶ID

%g 所dump進程的實際組ID

%s 導致本次core dump的信號

%t core dump的時間 (由1970年1月1日計起的秒數)

%h 主機名

%e 程序文件名

以上就是如何理解coredump，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。