Linux 下如何產生core文件（core dump設置）

轉自：https://blog.csdn.net/star_xiong/article/details/43529637

　　

　　今天在Linux下調試C程序時，出現段錯誤，習慣性的ls下當前目錄，發現沒有生成core文件。驚訝了一下，怎麼回事？之前都會產生的啊，難不成是程序的問題？後來同事提醒是否是系統沒有打開生成core dump的設置。

還真是系統設置問題，個人ubuntu14.04是新裝的，以前沒有進行過core dump的相關配置，別急！咱們來看看怎麼對linux系統設置當程序出現段錯誤時產生core文件：

一、先用#ulimit -a能夠查看系統core文件的大小限制（第一行），core文件大小設置爲0, 即沒有打開core dump設置；

root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 46621
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) 46621
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

二、接下來使用#ulimit -c [kbytes]能夠設置系統容許生成的core文件大小；
ulimit -c 0 不產生core文件
ulimit -c 100 設置core文件最大爲100k
ulimit -c unlimited 不限制core文件大小

執行#ulimit -c unlimited，而後#ulimit -a查看結果以下（第一行）：

root@XZX:~/cnnic/project/dnsx/dnsX# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 46621
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) 46621
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

此時，core dump設置打開了，再執行程序出現段錯誤時，在當前工做目錄下產生了core文件，而後咱們就能夠用gdb調試core文件了。

 例如：

#gdb ./test core.2065

注：Linux下的C程序經常會由於內存訪問錯誤等緣由形成segment fault(段錯誤)，此時若是系統core dump功能是打開的，那麼將會有內存映像轉儲到硬盤上來，以後能夠用gdb對core文件進行分析，還原系統發生段錯誤時刻的堆棧狀況。這對於咱們發現程序bug頗有幫助。

不少系統默認的core文件大小都是0，咱們能夠經過在shell的啓動腳本/etc/bashrc或者~/.bashrc等地方來加入 ulimit -c 命令來指定core文件大小，從而確保core文件可以生成。
除此以外，還能夠在/proc/sys/kernel/core_pattern裏設置core文件的文件名模板，詳情請看core的官方man手冊。

    須要說明的是：上述方法只是在當前shell中生效,重啓以後，就再也不有效了。永久生效的辦法是以下：

永久生效辦法：

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

ulimit -c 1073741824

  (可是，若將產生的轉儲文件大小大於該數字時，將不會產生轉儲文件)

或者

　　ulimit -c unlimited

這樣重啓機器後生效了。 或者， 使用source命令使之立刻生效。

 　　#source /etc/profile

3、指定內核轉儲的文件名和目錄

        修改完內核轉儲設置後，當程序core dump後發現確實在本地目錄產生了core文件，可是若是程序屢次core dump時，core文件會被覆蓋，緣由是每次core dump後生成的文件名默認都叫core，接下來就分享下若是想在每次core dum時產生的core文件都帶上進程號怎麼操做，或者你想把內核轉儲文件保存到其餘目錄怎麼辦？

一、core dump文件名自動加上進程ID

    #echo 1 > /proc/sys/kernel/core_uses_pid

最後生成的core dump文件名會加上進程ID.

二、另外能夠經過修改kernel的參數，指定內核轉儲所生成的core文件的路徑和文件名。

       能夠經過在/etc/sysctl.conf文件中，對sysctl變量kernel.core_pattern的設置。

       #vim /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_2456

更詳細的內容或手動強制某個進程產生core dump的方法見連接：http://blog.csdn.net/wj_j2ee/article/details/7161586

幫助連接：http://www.cppblog.com/API/archive/2012/10/22/193644.html