轉載自：http://blog.chinaunix.net/u2/83905/showart_2134570.html
在Unix系統下，應用程序崩潰，一般會產生core文件，如何根據core文件查找問題的所在，並做相應的分析和調試，是非常重要的。
什么是Core Dump?
Core的意思是內存, Dump的意思是扔出來, 堆出來.開發和使用Unix程序時, 有時程序莫名其妙的down了, 卻沒有任何的提示(有時候會提示core dumped). 這時候可以查看一下有沒有形如core.進程號的文件生成, 這個文件便是操作系統把程序down掉時的內存內容扔出來生成的, 它可以做為調試程序的參考.
core dump又叫核心轉儲, 當程序運行過程中發生異常, 程序異常退出時, 由操作系統把程序當前的內存狀況存儲在一個core文件中, 叫core dump.
為什么沒有core文件生成呢?
有時候程序down了, 但是core文件卻沒有生成. core文件的生成跟你當前系統的環境設置有關系, 可以用下面的語句設置一下, 然后再運行程序便成生成core文件.
ulimit -c unlimited
core文件生成的位置一般於運行程序的路徑相同, 文件名一般為core.進程號
當獲得了core文件以后，就可以利用命令gdb進行查找，參數一是應用程序的名稱，參數二是core文件
如： gdb [...]xmsd [...]/xmsd_PID1065_SIG11.core
然后輸入bt或者where找到錯誤發生的位置和相應的堆棧信息。就可知道發生錯誤時的函數調用關系，然后可以使用up或者down查看上一條和下一條具體詳細信息。這樣便能對問題進行大概定位，然后看源代碼，進行分析。
例子：
[root@typhoeus79 20131127]# gdb test ./core.11944 GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"... (no debugging symbols found) warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 (no debugging symbols found) Core was generated by `./test'. Program terminated with signal 11, Segmentation fault. [New process 11944] #0 0x00000000004004af in main () (gdb) where #0 0x00000000004004af in main () (gdb) bt #0 0x00000000004004af in main () (gdb) up Initial frame selected; you cannot go up. (gdb) down Bottom (innermost) frame selected; you cannot go down.