段錯誤（segfault）
"段錯誤"是程序試圖操作不允許訪問或試圖訪問的不允許內存的情況。可能導致段錯誤的原因主要有：
1、試圖解引用空指針（你不允許訪問內存地址0）
2、試圖解引用不在你內存中的其他指針
3、一個C vtable虛表指針被破壞并指向錯誤的地方，這導致程序試圖去執(zhí)行一些不可執(zhí)行的內存。
4、其他情況，比如未對齊的內存訪問也可能會出現(xiàn)段錯誤。
core dump 文件
在linux下當應用程序發(fā)生異常中止退出或者發(fā)生崩潰的時候，linux內核會將應用程序在這段運行期間的內存狀態(tài)等相關信息轉存到磁盤，以供系統(tǒng)故障排查或者調試。這個轉存的文件叫core dump文件。core dump文件中會記錄程序當時的內存調用、堆棧引用、進程和線程調用等信息，可以幫助開發(fā)人員和維護人員了解異常發(fā)生當時的環(huán)境參數(shù)和信息，所以core dump對故障排查和bug調試具有重大的意義。
要深入探究還得利用得core dump文件，下面我們就對其進一步探究：
如何獲得core dump
我們前面說了core dump是程序發(fā)生異常時候，其內存使用副本的轉存文件，當你需要調試程具體序出錯時的信息時候，它非常有用。
當程序發(fā)生段錯誤時，Linux內核有時會向磁盤寫入一個core dump文件。很多人可能疑惑按照教程一步一步來做了，但是最后沒有獲得所需的core dump。一般情況下系統(tǒng)設置不輸出core dump，所以沒有生成core dump文件。
如果沒有生成core dump文件，請按照以下步驟做設置：
1.在linux終端執(zhí)行以下命令 ulimit -c unlimited
2.運行sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
ulimit：
在linux下 通過ulimit -c設置core dump的最大值。它默認設置為0，這時候內核就不會生成core dump。它以KB為單位。 ulimit是按進程為單位進行設置的。我們可以通過運行cat /proc/PID/limit來查看具體某個進程的大小限制。
例如，這些是我的系統(tǒng)隨便一個nginx進程的大小限制：
cat /proc/8854/limits (PID換成你系統(tǒng)中具體的進程號，此處我的系統(tǒng)中進程號位8854)
內核通過soft limit值決定寫入core文件的大小 （例如上圖中我們的nginx"max core file size = 0"）。我們使用使用ulimit -c unlimited將軟限制無限制，core dump文件就可以無限增大。我們也可以用具體文件大小來替代umlimited的值。
kernel.core_pattern
kernel.core_pattern是內核參數(shù)，通過 sysctl命令來配置，用于控制Linux內核將core dump寫入磁盤的位置和文件名格式。
我們可以通過運行sysctl -a來獲取當前系統(tǒng)的所有內核參數(shù)和設置值得列表。或者使用sysctl kernel.core_pattern僅查看kernel.core_pattern的設置值。
sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t設置下core dump文件將被寫入/tmp/core-（標識進程的參數(shù)值）。具體關于%e.%p.%h參數(shù)的表示內容，請參閱man core。
Ubuntu下kernel.core_pattern設置
默認情況下，Ubuntu上， kernel.core_pattern設置的內容為：
sysctl kernel.core_pattern
kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P
這曾讓我很困惑，這是什么東西，它是怎么處理我的core dump的。所以我搜索相關資料了解到：
Ubuntu使用稱為"apport"的系統(tǒng)來記錄apt包管理器中的崩潰
設置kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P
表示core dump內容被重定向到apport，其日志為/var/log/apport.log
默認情況下，apport將忽略來非Ubuntu軟件包的二進制文件的那部分的崩潰日志。所以默認apport.log中默認也是不會記錄core dump信息的。為了得到core dump具體做法就是重新設置kernel.core_pattern的值，將其設為sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t。
用gdb進行追蹤
core dump中信息是支持用gdb做調試的，關于gdb是linux下一個強大的debug調試程序，不熟悉的同學，先搜索一下。
用下面的gdb命令打開一個core dump文件：
gdb -c my_core_file
接下來，我們想知道程序崩潰時的堆棧是什么。在gdb提示符下運行bt會給你一個堆棧追蹤。默認情況下，編譯時候沒有做符號調試，gdb無法加載二進制符號，所以追蹤結果中會都是??。如下圖所示：
這種情況下，我們需要加載符號符號表，使得顯示正常。可通過在gdb命令下執(zhí)行：
symbol-file 應用的執(zhí)行程序（絕對路徑）
sharedlibrary
這會從二進制程序文件及其引入的共享庫中加載符號。執(zhí)行后，再次輸入bt，gdb就會返回帶有行號堆棧跟蹤信息。
如果你想讓其工作正常，在做程序做調試時候應該啟用哦調試符號編譯（gcc -g）。在試圖找出程序崩潰的原因時，在堆棧跟蹤中有行號非常有用。
在gdb也可以查看每個線程的堆棧，具體方法如下： thread apply all bt full
來源：http://www.icode9.com/content-3-154201.html
