段錯誤（segfault）
"段錯誤"是程序試圖操作不允許訪問或試圖訪問的不允許內存的情況。可能導致段錯誤的原因主要有：
1、試圖解引用空指針（你不允許訪問內存地址0）
2、試圖解引用不在你內存中的其他指針
3、一個C++ vtable虛表指針被破壞並指向錯誤的地方，這導致程序試圖去執行一些不可執行的內存。
4、其他情況，比如未對齊的內存訪問也可能會出現段錯誤。
core dump 文件
在linux下當應用程序發生異常中止退出或者發生崩潰的時候，linux內核會將應用程序在這段運行期間的內存狀態等相關信息轉存到磁盤，以供系統故障排查或者調試。這個轉存的文件叫core dump文件。core dump文件中會記錄程序當時的內存調用、堆棧引用、進程和線程調用等信息，可以幫助開發人員和維護人員了解異常發生當時的環境參數和信息，所以core dump對故障排查和bug調試具有重大的意義。
要深入探究還得利用得core dump文件，下面我們就對其進一步探究：
如何獲得core dump
我們前面說了core dump是程序發生異常時候，其內存使用副本的轉存文件，當你需要調試程具體序出錯時的信息時候，它非常有用。
當程序發生段錯誤時，Linux內核有時會向磁盤寫入一個core dump文件。很多人可能疑惑按照教程一步一步來做了，但是最后沒有獲得所需的core dump。一般情況下系統設置不輸出core dump，所以沒有生成core dump文件。
如果沒有生成core dump文件，請按照以下步驟做設置：
1.在linux終端執行以下命令 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來查看具體某個進程的大小限制。
例如，這些是我的系統隨便一個nginx進程的大小限制：
cat /proc/8854/limits (PID換成你系統中具體的進程號，此處我的系統中進程號位8854)
內核通過soft limit值決定寫入core文件的大小 （例如上圖中我們的nginx"max core file size = 0"）。我們使用使用ulimit -c unlimited將軟限制無限制，core dump文件就可以無限增大。我們也可以用具體文件大小來替代umlimited的值。
kernel.core_pattern
kernel.core_pattern是內核參數，通過 sysctl命令來配置，用於控制Linux內核將core dump寫入磁盤的位置和文件名格式。
我們可以通過運行sysctl -a來獲取當前系統的所有內核參數和設置值得列表。或者使用sysctl kernel.core_pattern僅查看kernel.core_pattern的設置值。
sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t設置下core dump文件將被寫入/tmp/core-（標識進程的參數值）。具體關於%e.%p.%h參數的表示內容，請參閱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"的系統來記錄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命令下執行：
symbol-file 應用的執行程序（絕對路徑）
sharedlibrary
這會從二進制程序文件及其引入的共享庫中加載符號。執行后，再次輸入bt，gdb就會返回帶有行號堆棧跟蹤信息。
如果你想讓其工作正常，在做程序做調試時候應該啟用哦調試符號編譯（gcc -g）。在試圖找出程序崩潰的原因時，在堆棧跟蹤中有行號非常有用。
在gdb也可以查看每個線程的堆棧，具體方法如下： thread apply all bt full