1.core文件的生成開關和大小限制
---------------------------------
1）使用ulimit
-c命令可查看core文件的生成開關。若結果為0，則表示關閉了此功能，不會生成core文件。
2）
使用ulimit
-cfilesize命令，可以限制core文件的大小（filesize的單位為kbyte）。若ulimit
-cunlimited，則表示core文件的大小不受限制。如果生成的信息超過此大小，將會被裁剪，最終生成一個不完整的core文件。在調試此
core文件的時候，gdb會提示錯誤。
2.core文件的名稱和生成路徑
----------------------------

一、設置core文件相關參數
若系統生成的core文件不帶其它任何擴展名稱，則全部命名為core。新的core文件生成將覆蓋原來的core文件。
1）/proc/sys/kernel/core_uses_pid可以控制core文件的文件名中是否添加pid作為擴展。文件內容為1，表示添加pid作為擴展名，生成的core文件格式為core.xxxx；為0則表示生成的core文件同一命名為core。
可通過以下命令修改此文件：
echo
"1" >
/proc/sys/kernel/core_uses_pid
2）proc/sys/kernel/core_pattern可以控制core文件保存位置和文件名格式。
可通過以下命令修改此文件：
echo
"/corefile/core-%e-%p-%t" >
core_pattern，可以將core文件統一生成到/corefile目錄下，產生的文件名為core-命令名-pid-時間戳
以下是參數列表:
? ?
%p - insert pid into filename 添加pid
? ?
%u - insert current uid into filename 添加當前uid
? ?
%g - insert current gid into filename 添加當前gid
? ?
%s - insert signal that caused the coredump into the filename
添加導致產生core的信號
? ?
%t - insert UNIX time that the coredump occurred into filename
添加core文件生成時的unix時間
? ?
%h - insert hostname where the coredump happened into filename
添加主機名
? ?
%e - insert coredumping executable name into filename
添加命令名
二、.用gdb查看core文件:
發生coredump之后,用gdb進行查看core文件的內容,以定位文件中引發coredump的行.
gdb [execfile] [core file]
如:
gdb ./test core.22773
gdb core_dump_test core.22773
在進入gdb后,
用bt命令查看backtrace以檢查發生程序運行到哪里,
來定位core dump的文件->行.

三、調試core文件

Unix系統下，應用程序崩潰，一般會產生core文件，如何根據core文件查找問題的所在，并做相應的分析和調試，是非常重要的，本文對此做簡單介紹。

例如，一個程序cmm_test_tool在運行的時候發生了錯誤，并生成了一個core文件，如下：

-rw-r–r– 1 root cmm_test_tool.c
-rw-r–r– 1 root cmm_test_tool.o
-rwxr-xr-x 1 root cmm_test_tool
-rw——- 1 root core.19344
-rw——- 1 root core.19351
-rw-r–r– 1 root cmm_test_tool.cfg
-rw-r–r– 1 root cmm_test_tool.res
-rw-r–r– 1 root cmm_test_tool.log
[root@AUTOTEST_SIM2 mam2cm]#

就可以利用命令gdb進行查找，參數一是應用程序的名稱，參數二是core文件，運行
gdb cmm_test_tool core.19344結果如下：

[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 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”…
Core was generated by `./cmm_test_tool’.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/i686/libpthread.so.0…done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /usr/lib/libz.so.1…done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.5…done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/libgcc_s.so.1…done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2…done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2…done.
Loaded symbols for /lib/libnss_files.so.2
#0 0x4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6
(gdb)

進入gdb提示符，輸入where，找到錯誤發生的位置和堆棧，如下：

(gdb) where
#0 0x4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6
#1 0x4202d4e7 in strtoul () from /lib/i686/libc.so.6
#2 0x0804b4da in GetMaxIDFromDB (get_type=2, max_id=0x806fd20) at cmm_test_tool.c:788
#3 0x0804b9d7 in ConstrctVODProgram (vod_program=0x40345bdc) at cmm_test_tool.c:946
#4 0x0804a2f4 in TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0×40021941 in pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)

至此，可以看出文件出錯的位置是函數 GetMaxIDFromDB ，兩個參數分別是2和0x806fd20，這個函數位于源代碼的788行，基于此，我們就可以有針對性的找到問題的根源，并加以解決。

?

總結

以上是生活随笔為你收集整理的如何设置、查看以及调试core文件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。