從接觸unix開始就一直聽到和遇到core mp，特別是剛學著使用C語言在AIX下編寫程序的時候， mp更是時不時就會不請自來。記得當時剛寫應用的時候，提交程序時最怕的就是在運行過程時遇到core mp，對於銀行核心系統，特別是使用靜態應用進程，如果一個相對頻繁一點的交易導致core mp，那麼毫無疑問，除了趕緊定位錯誤改程序外，重啟進程甚至無法爭取到多少緩沖的時間來進行代碼的更正和測試。而且往往導致core mp的，就是程序中一個小小的未注意到或者未測試到的一個疏忽。
雖然常常遇到core mp，不過很長時間內，都是出於知道這個名字，知道它導致的後果，知道一部分導致它出現的原因，其他的就都不甚了了了。說起來，就是自己太懶了，懶得看書......少壯不努力啊。看過一則統計，說60歲以上的老人，超過70%都後悔少壯不努力，不知統計的數據能否反映整個社會的情況。不過總的來說，這句古話還是有些道理的。大家不要學我。哈哈
core mp，翻譯過來講，就是核心轉儲。大致上就是指，如果由於應用錯誤，如浮點異常、指令異常等，操作系統將會轉入內核的異常處理，向對應的進程發送特定的信號（SIGNAL），如果進程中沒有對這些信號進行處理，就會轉入默認的處理，core mp就是其中的一種。如果進程core mp，系統將會終止該進程，同時系統會產生core文件，以供調試使用。這個core文件其實就是內存的映像，即進程執行的時候內存的內容，也就是所謂的core mp。平常大家說某某進程core mp了，其實主要的意思就是說：某某進程因為錯誤而被系統自動終止了。
AIX上提供了dbx工具可以對core mp進行調試，協助定位引起core mp的代碼。最普通的語法是：
dbx 應用名 core文件， 然後使用where命令來顯示調試信息
一般來講，根據工作中遇到的情況，dbx還是能夠比較輕松的根據提示的內容來定位代碼的。不過也有一些特殊情況時，dbx顯示的調試信息過於模糊或者不直觀，這個時候就只能根據經驗來逐步定位了。有時定位起來會耗用相當長的時間。遇到這種情況時，使用日誌文件，通過在代碼中穿插多個寫log的語句，也可以協助發現。因為進程core mp時，日誌當然也中斷了，根據日誌在哪個代碼行之後或之前中止了，可以有效縮小尋找的范圍。甚至，在有些情況下，使用日誌定位是唯一簡便的方法了。
B. 怎樣用GDB調試core文件
一般這種情況都是因為數組越界訪問，空指針或是野指針讀寫造成的。程序小的話還比較好辦，對著源代碼仔細檢查就能解決。但是對於代碼量較大的程序，里邊包含N多函數調用，N多數組指針訪問，這時想定位問題就不是很容易了（此時牛人依然可以通過在適當位置打printf加二分查找的方式迅速定位:P）。懶人的話還是直接GDB搞起吧。 神馬是Core Dump文件偶爾就能聽見某程序員同學抱怨「擦，又出Core了！」。簡單來說，core mp說的是操作系統執行的一個動作，當某個進程因為一些原因意外終止（crash）的時候，操作系統會將這個進程當時的內存信息轉儲（mp）到磁碟上1。產生的文件就是core文件了，一般會以core.xxx形式命名。 如何產生Core Dump 發生doremp一般都是在進程收到某個信號的時候，Linux上現在大概有60多個信號，可以使用 kill -l 命令全部列出來。sagi@sagi-laptop:~$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX針對特定的信號，應用程序可以寫對應的信號處理函數。如果不指定，則採取默認的處理方式, 默認處理是coremp的信號如下：3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS 5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT 我們看到SIGSEGV在其中，一般數組越界或是訪問空指針都會產生這個信號。另外雖然默認是這樣的，但是你也可以寫自己的信號處理函數改變默認行為，更多信號相關可以看參考鏈接33。 上述內容只是產生coremp的必要條件，而非充分條件。要產生core文件還依賴於程序運行的shell，可以通過ulimit -a命令查看，輸出內容大致如下：sagi@sagi-laptop:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheling 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 看到第一行了吧，core file size，這個值用來限制產生的core文件大小，超過這個值就不會保存了。我這里輸出是0，也就是不會保存core文件，即使產生了，也保存不下來==! 要改變這個設置，可以使用ulimit -c unlimited。 OK, 現在萬事具備，只缺一個能產生Core的程序了，介個對C程序員來說太容易了。#include ; #include ; int crash() { char *xxx = "crash!!"; xxx[1] = 'D'; // 寫只讀存儲區! return 2; } int foo() { return crash(); } int main() { return foo(); } 上手調試 上邊的程序編譯的時候有一點需要注意，需要帶上參數-g, 這樣生成的可執行程序中會帶上足夠的調試信息。編譯運行之後你就應該能看見期待已久的「Segment Fault(core mped)」或是「段錯誤 (核心已轉儲)」之類的字眼了。看看當前目錄下是不是有個core或是core.xxx的文件。祭出linux下經典的調試器GDB，首先帶著core文件載入程序：gdb exefile core，這里需要注意的這個core文件必須是exefile產生的，否則符號表會對不上。載入之後大概是這個樣子的：sagi@sagi-laptop:~$ gdb coremp core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in crash () at coremp.c:8 8 xxx[1] = 'D'; (gdb)我們看到已經能直接定位到出core的地方了，在第8行寫了一個只讀的內存區域導致觸發Segment Fault信號。在載入core的時候有個小技巧，如果你事先不知道這個core文件是由哪個程序產生的，你可以先隨便找個代替一下，比如/usr/bin/w就是不錯的選擇。比如我們採用這種方法載入上邊產生的core，gdb會有類似的輸出：sagi@sagi-laptop:~$ gdb /usr/bin/w core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in ? () (gdb)可以看到GDB已經提示你了，這個core是由哪個程序產生的。 GDB 常用操作 上邊的程序比較簡單，不需要另外的操作就能直接找到問題所在。現實卻不是這樣的，常常需要進行單步跟蹤，設置斷點之類的操作才能順利定位問題。下邊列出了GDB一些常用的操作。 啟動程序：run
設置斷點：b 行號|函數名
刪除斷點：delete 斷點編號
禁用斷點：disable 斷點編號
啟用斷點：enable 斷點編號
單步跟蹤：next 也可以簡寫 n
單步跟蹤：step 也可以簡寫 s
列印變數：print 變數名字
設置變數：set var=value
查看變數類型：ptype var
順序執行到結束：cont
順序執行到某一行： util lineno列印堆棧信息：bt
C. linux 小調用執行程序時 產生core文件，gdb調試時如下信息：
用gdb調試工具。 1、gcc -g 1.c 2、執行 目的是產生core文件 3、gdb ./a.out core 4、where
D. 誰能告訴我linux下出core，core究竟是什麼
就是一個程序出錯時，相關的調試信息，生成的一個文件。
可以對它調試，得到出錯原因。
用gdb就可以了。但你的程序必須帶gdb信息。
也就是說，在編譯的時候要指定-g 參數。
E. linux下終端運行文件，代碼沒有錯誤，為什麼出現段錯誤。
你代碼也沒有，調用堆棧也沒有，誰能知道為啥段錯誤啊，要不然你猜我今天穿什麼顏色的衣服？
大神也不敢說自己的代碼肯定就沒有錯誤，我猜你的意思是能正確編譯吧？
那隻能說明你的語法沒錯，僅此而已，寫程序能正確編譯只是第一步，後面調試的滑塌敗工作還很漫長。
下面說說怎麼調試吧：
看你的系統提示應該還沒有打開core輸出，在運行程序前打個命令：
ulimit -c unlimited
這樣設置之後再運行程序在段錯誤的時候能core mp，有core之後再gdb ./test core.xxx
core文件一般在你運行程序的目錄里，core文件後綴每次不同，後面的xxx你需要自衫蘆己看看文件名，一般是運行時的PID號。當然如果你的系統core的生成規則被改過，不是默認的，那就問你的系統管理員去找到core文件。
進去後打個bt，看下當前的調用堆棧，然後再看下哪兒出的問題。
當然這樣做有個前提，那就是你在編譯信顫你的程序時加了-g參數，如果沒有，重新去編譯下再運行。
如果還是找不出來，再把你的調用堆棧和代碼發上來大家看看。
F. linux core 怎麼打開
core文件是由應用程序收到系統信號後崩潰產生的，該文件中記錄了程序崩潰的原因(例如收到那種信號)，調用堆棧和崩潰時的內存及變數值等等的信息。
打開core文件與編譯時使用的編譯器有關，但絕大多數linux程序是使用gcc編譯器編譯的，因此可使用對應gdb調試器打開，命令格式如下：
$ gdb 應用程序文件名 core文件名
舉例：
$ gdb /usr/bin/gedit ~/core ------ 查看由gedit崩潰產生的core文件
(gdb) bt ------ 或者backtrace, 查看程序運行到當前位置之前所有的堆棧幀情況)
(gdb) quit ------ 退出
如果不知道core文件由哪個文件產生的，可使用file命令顯示
$ file core
G. RedHat Linux下如何生成core mp文件
在linux平台下，設置core mp文件生成的方法：
1 ）如何生成 coremp 文件
登陸 LINUX 伺服器，任意位置鍵入
echo "ulimit -c 1024" >> /etc/profile
退出 LINUX 重新登陸 LINUX
鍵入 ulimit -c
如果顯示 1024 那麼說明 coremp 已經被開啟。
1024 限制產生的 core 文件的大小不能超過 1024kb，可以使用參數unlimited，取消該限制
ulimit -c unlimited
2 ） . core 文件的簡單介紹
在一個程序崩潰時，它一般會在指定目錄下生成一個 core 文件。 core 文件僅僅是一個內存映象 ( 同時加上調試信息 ) ，主要是用來調試的。
3 ） . 開啟或關閉 core 文件的生成
用以下命令來阻止系統生成 core 文件 :
ulimit -c 0
下面的命令可以檢查生成 core 文件的選項是否打開 :
ulimit -a
該命令將顯示所有的用戶定製，其中選項 -a 代表「 all 」。
也可以修改系統文件來調整 core 選項
在 /etc/profile 通常會有這樣一句話來禁止產生 core 文件，通常這種設置是合理的 :
# No core files by default
ulimit -S -c 0 > /dev/null 2>&1
但是在開發過程中有時為了調試問題，還是需要在特定的用戶環境下打開 core 文件產生的設置。
在用戶的 ~/.bash_profile 里加上 ulimit -c unlimited 來讓特定的用戶可以產生 core 文件。
如果 ulimit -c 0 則也是禁止產生 core 文件，而 ulimit -c 1024 則限制產生的 core 文件的大小不能超過 1024kb
4 ） . 設置 Core Dump 的核心轉儲文件目錄和命名規則
/proc/sys/kernel/core_uses_pid 可以控制產生的 core 文件的文件名中是否添加 pid 作為擴展 ，如果添加則文件內容為 1 ，否則為 0
proc/sys/kernel/core_pattern 可以設置格式化的 core 文件保存位置或文件名 ，比如原來文件內容是 core-%e
可以這樣修改 :
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 coremp into the filename 添加導致產生 core 的信號
%t - insert UNIX time that the coremp occurred into filename 添加 core 文件生成時的 unix 時間
%h - insert hostname where the coremp happened into filename 添加主機名
%e - insert coremping executable name into filename 添加命令名
6 ） . 一個小方法來測試產生 core 文件
直接輸入指令 :
kill -s SIGSEGV $$
發生coremp一般都是在進程收到某個信號的時候，Linux上現在大概有60多個信號，可以使用 kill -l 命令全部列出來。
針對特定的信號，應用程序可以寫對應的信號處理函數。如果不指定，則採取默認的處理方式, 默認處理是coremp的信號如下：
3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS
5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT
我們看到SIGSEGV在其中，一般數組越界或是訪問空指針都會產生這個信號。另外雖然默認是這樣的，但是你也可以寫自己的信號處理函數改變默認行為。
上述內容只是產生coremp的必要條件，而非充分條件。要產生core文件還依賴於程序運行的shell，可以通過ulimit -a命令查看
H. 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
ing」 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
0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
(gdb)
進入gdb提示符，輸入where，找到錯誤發生的位置和堆棧，如下:
(gdb) where
#0 0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
#1 0×4202d4e7 in strtoul () from
/lib/i686/libc.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_tool.c:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0×0804a2f4 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和0×806fd20，這個函數位於源代碼的788行，基於此，我們就可以有針對性的找到問題的根源，並加以解決。
I. linux c內存溢出的core mp bug怎麼跟
淺析Linux下core文件
當我們的程序崩潰時，內核有可能把該程序當前內存映射到core文件里，方便程序員找到程序出現問題的地方。最常出 現的，幾乎所有C程序員都出現過的錯誤就是「段錯誤」了。也是最難查出問題原因的一個錯誤。下面我們就針對「段錯誤」來分析core文件的產生、以及我們 如何利用core文件找到出現崩潰的地方。
何謂core文件
當一個程序崩潰時，在進程當前工作目錄的core文件中復制了該進程的存儲圖像。core文件僅僅是一個內存映象(同時加上調試信息)，主要是用來調試的。
當程序接收到以下UNIX信號會產生core文件：
名字
說明
ANSI C POSIX.1
SVR4 4.3+BSD
預設動作
SIGABRT
異常終止(abort)
. .
. .
終止w/core
SIGBUS
硬體故障
.
. .
終止w/core
SIGEMT
硬體故障
. .
終止w/core
SIGFPE
算術異常
. .
. .
終止w/core
SIGILL
非法硬體指令
. .
. .
終止w/core
SIGIOT
硬體故障
. .
終止w/core
SIGQUIT
終端退出符
.
. .
終止w/core
SIGSEGV
無效存儲訪問
. .
. .
終止w/core
SIGSYS
無效系統調用
. .
終止w/core
SIGTRAP
硬體故障
. .
終止w/core
SIGXCPU
超過CPU限制(setrlimit)
. .
終止w/core
SIGXFSZ
超過文件長度限制(setrlimit)
. .
終止w/core
在系統默認動作列，「終止w/core」表示在進程當前工作目錄的core文件中復制了該進程的存儲圖像（該文件名為core，由此可以看出這種功能很久之前就是UNIX功能的一部分）。大多數UNIX調試程序都使用core文件以檢查進程在終止時的狀態。
core文件的產生不是POSIX.1所屬部分,而是很多UNIX版本的實現特徵。UNIX第6版沒有檢查條件 (a)和(b)，並且其源代碼中包含如下說明：「如果你正在找尋保護信號，那麼當設置-用戶-ID命令執行時，將可能產生大量的這種信號」。4.3 + BSD產生名為core.prog的文件，其中prog是被執行的程序名的前1 6個字元。它對core文件給予了某種標識，所以是一種改進特徵。
表中「硬體故障」對應於實現定義的硬體故障。這些名字中有很多取自UNIX早先在DP-11上的實現。請查看你所使用的系統的手冊，以確切地確定這些信號對應於哪些錯誤類型。
下面比較詳細地說明這些信號。
• SIGABRT 調用abort函數時產生此信號。進程異常終止。
• SIGBUS 指示一個實現定義的硬體故障。
• SIGEMT 指示一個實現定義的硬體故障。
EMT這一名字來自PDP-11的emulator trap 指令。
• SIGFPE 此信號表示一個算術運算異常，例如除以0，浮點溢出等。
• SIGILL 此信號指示進程已執行一條非法硬體指令。
4.3BSD由abort函數產生此信號。SIGABRT現在被用於此。
• SIGIOT 這指示一個實現定義的硬體故障。
IOT這個名字來自於PDP-11對於輸入／輸出TRAP(input/output TRAP)指令的縮寫。系統V的早期版本，由abort函數產生此信號。SIGABRT現在被用於此。
• SIGQUIT 當用戶在終端上按退出鍵（一般採用Ctrl-\）時，產生此信號，並送至前台進
程組中的所有進程。此信號不僅終止前台進程組（如SIGINT所做的那樣），同時產生一個core文件。
• SIGSEGV 指示進程進行了一次無效的存儲訪問。
名字SEGV表示「段違例（segmentation violation）」。
• SIGSYS 指示一個無效的系統調用。由於某種未知原因，進程執行了一條系統調用指令，
但其指示系統調用類型的參數卻是無效的。
• SIGTRAP 指示一個實現定義的硬體故障。
此信號名來自於PDP-11的TRAP指令。
• SIGXCPU SVR4和4.3+BSD支持資源限制的概念。如果進程超過了其軟C P U時間限制，則產生此信號。
• SIGXFSZ 如果進程超過了其軟文件長度限制，則SVR4和4.3+BSD產生此信號。
摘自《UNIX環境高級編程》第10章 信號。
使用core文件調試程序
看下面的例子：
/*core_mp_test.c*/
#include
const char *str = "test";
void core_test(){
str[1] = 'T';
}
int main(){
core_test();
return 0;
}
編譯：
gcc –g core_mp_test.c -o core_mp_test
如果需要調試程序的話，使用gcc編譯時加上-g選項，這樣調試core文件的時候比較容易找到錯誤的地方。
執行：
./core_mp_test
段錯誤
運行core_mp_test程序出現了「段錯誤」，但沒有產生core文件。這是因為系統默認core文件的大小為0，所以沒有創建。可以用ulimit命令查看和修改core文件的大小。
ulimit -c 0
ulimit -c 1000
ulimit -c 1000
-c 指定修改core文件的大小，1000指定了core文件大小。也可以對core文件的大小不做限制，如：
ulimit -c unlimited
ulimit -c unlimited
如果想讓修改永久生效，則需要修改配置文件，如 .bash_profile、/etc/profile或/etc/security/limits.conf。
再次執行：
./core_mp_test
段錯誤 (core mped)
ls core.*
core.6133
可以看到已經創建了一個core.6133的文件.6133是core_mp_test程序運行的進程ID。
調式core文件
core文件是個二進制文件，需要用相應的工具來分析程序崩潰時的內存映像。
file core.6133
core.6133: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'core_mp_test'
在Linux下可以用GDB來調試core文件。
gdb core_mp_test core.6133
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 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 ing" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Core was generated by `./core_mp_test'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x080482fd in core_test () at core_mp_test.c:7
7 str[1] = 'T';
(gdb) where
#0 0x080482fd in core_test () at core_mp_test.c:7
#1 0x08048317 in main () at core_mp_test.c:12
#2 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
GDB中鍵入where，就會看到程序崩潰時堆棧信息（當前函數之前的所有已調用函數的列表（包括當前函數），gdb只顯示最近幾個），我們很容易找到我們的程序在最後崩潰的時候調用了core_mp_test.c 第7行的代碼，導致程序崩潰。注意：在編譯程序的時候要加入選項-g。您也可以試試其他命令，如fram、list等。更詳細的用法，請查閱GDB文檔。
core文件創建在什麼位置
在進程當前工作目錄的下創建。通常與程序在相同的路徑下。但如果程序中調用了chdir函數，則有可能改變了當前工 作目錄。這時core文件創建在chdir指定的路徑下。有好多程序崩潰了，我們卻找不到core文件放在什麼位置。和chdir函數就有關系。當然程序 崩潰了不一定都產生core文件。
什麼時候不產生core文件
在下列條件下不產生core文件：
( a )進程是設置-用戶-ID，而且當前用戶並非程序文件的所有者；
( b )進程是設置-組-ID，而且當前用戶並非該程序文件的組所有者；
( c )用戶沒有寫當前工作目錄的許可權；
( d )文件太大。core文件的許可權(假定該文件在此之前並不存在)通常是用戶讀/寫，組讀和其他讀。
利用GDB調試core文件，當遇到程序崩潰時我們不再束手無策。
J. linux 下如何打開core mp文件開關
mp文件可以在程序crash時，方便我們查看程序crash的地方和上下文信息。在window下，要能生成mp文件，需要自己編寫相應的代碼。不過現在網上可以找到相應的代碼，只要把它下載後然後加到自己的工程中去，就可以了！ 在linux下面就簡單的許多。只要打開相應的開關，linux會自動在程序crash時生成相應的core文件。這個文件和window下的mp文件類似。 下面是簡單的一些步驟： 1.查看當前是否已經打開了此開關 通過命令：ulimit -c 如果輸出為 0 ，則代表沒有打開。如果為unlimited則已經打開了,就沒必要在做打開。 2.通過命令打開 ulimit -c unlimited .然後通過步驟1，可以監測是否打開成功。 3.如果你要取消，很簡單：ulimit -c 0 就可以了 通過上面的命令修改後，一般都只是對當前會話起作用，當你下次重新登錄後，還是要重新輸入上面的命令，所以很麻煩。我們可以把通過修改 /etc/profile文件 來使系統每次自動打開。步驟如下： 1.首先打開/etc/profile文件 一般都可以在文件中找到 這句語句：ulimit -S -c 0 /dev/null 2&1.ok，根據上面的例子，我們只要把那個0 改為 unlimited 就ok了。然後保存退出。 2.通過source /etc/profile 使當期設置生效。 3.通過ulimit -c 查看下是否已經打開。 其實不光這個命令可以加入到/etc/profile文件中，一些其他我們需要每次登錄都生效的都可以加入到此文件中，因為登錄時linux都會載入此文件。比如一些環境變數的設置。 還有一種方法可以通過修改/etc/security/limits.conf文件來設置，這個方法沒有試過，也是網上看到。不過上面兩種就可以了！ 最後說一下生成core mp文件的位置，默認位置與可執行程序在同一目錄下，文件名是core.***，其中***是一個數字。core mp文件名的模式保存在/proc/sys/kernel/core_pattern中，預設值是core。通過以下命令可以更改core mp文件的位置(如希望生成到/tmp/cores目錄下) echo 「/tmp/cores/core」 /proc/sys/kernel/core_pattern 設置完以後我們可以做個測試，寫個程序，產生一個異常。然後看到當前目錄會有個core*的文件。然後我們可以 gdb core。* 程序 進行調試。