最近專案中出現了乙個問題，伺服器端程式會突然崩潰退出，我們採取了coredump技術以找到崩潰原因，即確定程序退出時正在執行的函式是哪個，其狀態如何。
如果系統開啟了coredump，準確的說如果當前的shell環境開啟了coredump，當前shell環境下的程式崩潰退出時，會把當時程序的棧的記憶體狀態寫入core檔案。使用gdb可以檢視這個core檔案中儲存的棧的狀態，gdb a.out core。（關於coredump的開啟和對shell的理解，請參考本人另一篇部落格《由coredump的開啟引起的對shell的深入**》，關於gdb請參考《gdb觀察棧的記憶體布局》）
core檔案生成的位置預設是可執行檔案所在的位置，名稱預設為core，其位置和名稱是可以設定的，我的設定為：
mkdir /home/corefile
echo 「/home/corefile/core-%e-%p-%t」 > /proc/sys/kernel/core_pattern
這樣，生成的core檔案會放在/home/corefile目錄下，core檔名會以core-%e-%p-%t的形式出現，其中%e表示可執行檔案的名稱，%p表示程序，%t表示生成core檔案的時間（注意是unix時間）。
下面是乙個可以導致coredump的例程：
#includeint square(inta, int b)
int docalc(intnum1, int num2)
int main()
劃線處是會導致coredump處。執行後會在/home/corefile目錄下產生以下檔案：
[root@localhostwin7]# ls /home/corefile/
core-a.out-5082-1490760381
a.out是可執行檔名，5082是pid，1490760381是產生該檔案的unix時間。把a.out 和core檔案放在乙個目錄下，使用命令：
gdb a.out core-a.out-5082-1490760381
進入gdb，然後使用backtrace命令，即可看程序退出時的棧的記憶體狀態，如下所示：
(gdb) bt#0 0x00000000004005ba in square(a=1, b=2) at gdbtest.cpp:7
#1 0x00000000004005e2 in docalc(num1=1, num2=2) at gdbtest.cpp:12
#2 0x000000000040060f in main () at gdbtest.cpp:19
qt程式崩潰生成core dump
二 qt程式 1 qt程式的除錯過程與命令列大同小異，首先編寫崩潰程式如下 void mainwindow on checkbox toggled bool 當勾選checkbox的時候，程式崩潰 2 修改qt程式的makefile，在圖中位置增添 g引數，再進行編譯 2 這裡將程式設定成自啟動，在...
讓程式崩潰後生成Core Dump
我們可以生成core dump檔案，並用gdb重現崩潰時的場景。ulimit設定core dump開關和大小 1ulimit c unlimited 測試 01 include 02 03 04intmain intargc,char argv 05 編譯 1gcc g 2.main.c o mai...
讓程式崩潰後生成Core Dump
在linux下，程式崩潰是很頭疼的事情 其實windows更是如此 我們可以生成core dump檔案，並用gdb重現崩潰時的場景。ulimit設定core dump開關和大小 1 ulimit c unlimited 測試 12 3 4 5 6 7 8 9 10 11 include intmai...