什么是core dump
程序由於收到某些特定的signal之后終止了，終止過程中會產生core文件，
core文件中包含了程序終止時的內存的狀態,這個過程就是core dump。
使用gdb工具結合可執行程序和debug symbol就能夠查訓到只要是類unix系統，都有這個機制。
具體哪些signal會時程序產生 core dump文件，這個可以通過man 7 signal查看。
coredump文件的存儲位置
注意： mac系統是存儲在固定的/cores/ 目錄下的
core文件默認的存儲位置與對應的可執行程序在同一目錄下，文件名是core，大家可以通過下面的命令看到core文件的存在位置：
cat /proc/sys/kernel/core_pattern
缺省值是core
注意：這里是指在進程當前工作目錄的下創建。通常與程序在相同的路徑下, 程序中可以調用chdir函數，來改變當前工作目錄。
這時core文件創建在chdir指定的路徑下。
通過下面的命令可以更改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。
由於core文件本身就是程序的內存的使用的一個表現，上面的方式也沒有提供方法來合理的存儲這些core文件，打開了core dump功能的話，磁盤空間很快就會沒有了，
所以linux 2.6.19以后引入了管道符號”|”, core dump的內容會通過管道輸入到你自己的core dump處理程序，你可以對core dump的內容進行二次處理，有效的減小系統存儲core文件所需要的空間
如何判斷一個文件是coredump文件？
在類unix系統下，coredump文件本身主要的格式也是ELF格式，因此，我們可以通過readelf命令進行判斷。
readelf -h core ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: CORE (Core file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 25 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0
注意：
Mac下可以使用 otool 工具查看
otool -hv /cores/core.79119 /cores/core.79119: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 CORE 56 5416 0x00000000
可以看到ELF文件頭的Type字段的類型是：CORE (Core file)
當然也可以通過簡單的file命令進行快速判斷：
file core core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './a.out'
file /cores/core.79119 /cores/core.79119: Mach-O 64-bit core x86_64
產生coredum的條件
1， 產生coredump的條件，首先需要確認當前會話的ulimit –c，若為0，則不會產生對應的coredump，需要進行修改和設置。
ulimit -c unlimited (可以產生coredump且不受大小限制)
若想甚至對應的字符大小，則可以指定：
ulimit –c [size]
可以看出，這里的size的單位是blocks,一般1block=512bytes
這里值設定的太小的話決不能生成core dump文件，或者core dump 文件被截斷了，這樣會影響問題的調查
最理想方式就是設定成程序使用的最大內存數，無法預估的話，推薦設定為ulimited.
當前設置的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在不同的環境，存儲的目錄可能不同，suse下可能在/etc/rc.d/rc.local
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.
注意: 如果設定為pipe方式的話，core dump 將無視ulimit的值的設定