段錯誤（segfault）

"段錯誤"是程序試圖操作不允許訪問或試圖訪問的不允許內(nèi)存的情況?？赡軐е露五e誤的原因主要有：

1、試圖解引用空指針（你不允許訪問內(nèi)存地址0）

2、試圖解引用不在你內(nèi)存中的其他指針

3、一個C vtable虛表指針被破壞并指向錯誤的地方，這導致程序試圖去執(zhí)行一些不可執(zhí)行的內(nèi)存。

4、其他情況，比如未對齊的內(nèi)存訪問也可能會出現(xiàn)段錯誤。

core dump 文件

在linux下當應(yīng)用程序發(fā)生異常中止退出或者發(fā)生崩潰的時候，linux內(nèi)核會將應(yīng)用程序在這段運行期間的內(nèi)存狀態(tài)等相關(guān)信息轉(zhuǎn)存到磁盤，以供系統(tǒng)故障排查或者調(diào)試。這個轉(zhuǎn)存的文件叫core dump文件。core dump文件中會記錄程序當時的內(nèi)存調(diào)用、堆棧引用、進程和線程調(diào)用等信息，可以幫助開發(fā)人員和維護人員了解異常發(fā)生當時的環(huán)境參數(shù)和信息，所以core dump對故障排查和bug調(diào)試具有重大的意義。

要深入探究還得利用得core dump文件，下面我們就對其進一步探究：

如何獲得core dump

我們前面說了core dump是程序發(fā)生異常時候，其內(nèi)存使用副本的轉(zhuǎn)存文件，當你需要調(diào)試程具體序出錯時的信息時候，它非常有用。

當程序發(fā)生段錯誤時，Linux內(nèi)核有時會向磁盤寫入一個core dump文件。很多人可能疑惑按照教程一步一步來做了，但是最后沒有獲得所需的core dump。一般情況下系統(tǒng)設(shè)置不輸出core dump，所以沒有生成core dump文件。

如果沒有生成core dump文件，請按照以下步驟做設(shè)置：

1.在linux終端執(zhí)行以下命令 ulimit -c unlimited

2.運行sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t

ulimit：

在linux下 通過ulimit -c設(shè)置core dump的最大值。它默認設(shè)置為0，這時候內(nèi)核就不會生成core dump。它以KB為單位。 ulimit是按進程為單位進行設(shè)置的。我們可以通過運行cat /proc/PID/limit來查看具體某個進程的大小限制。

例如，這些是我的系統(tǒng)隨便一個nginx進程的大小限制：

cat /proc/8854/limits (PID換成你系統(tǒng)中具體的進程號，此處我的系統(tǒng)中進程號位8854)

內(nèi)核通過soft limit值決定寫入core文件的大小 （例如上圖中我們的nginx"max core file size = 0"）。我們使用使用ulimit -c unlimited將軟限制無限制，core dump文件就可以無限增大。我們也可以用具體文件大小來替代umlimited的值。

kernel.core_pattern

kernel.core_pattern是內(nèi)核參數(shù)，通過 sysctl命令來配置，用于控制Linux內(nèi)核將core dump寫入磁盤的位置和文件名格式。

我們可以通過運行sysctl -a來獲取當前系統(tǒng)的所有內(nèi)核參數(shù)和設(shè)置值得列表。或者使用sysctl kernel.core_pattern僅查看kernel.core_pattern的設(shè)置值。

sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t設(shè)置下core dump文件將被寫入/tmp/core-（標識進程的參數(shù)值）。具體關(guān)于%e.%p.%h參數(shù)的表示內(nèi)容，請參閱man core。

Ubuntu下kernel.core_pattern設(shè)置

默認情況下，Ubuntu上， kernel.core_pattern設(shè)置的內(nèi)容為：

sysctl kernel.core_pattern

kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P

這曾讓我很困惑，這是什么東西，它是怎么處理我的core dump的。所以我搜索相關(guān)資料了解到：

Ubuntu使用稱為"apport"的系統(tǒng)來記錄apt包管理器中的崩潰

設(shè)置kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P

表示core dump內(nèi)容被重定向到apport，其日志為/var/log/apport.log

默認情況下，apport將忽略來非Ubuntu軟件包的二進制文件的那部分的崩潰日志。所以默認apport.log中默認也是不會記錄core dump信息的。為了得到core dump具體做法就是重新設(shè)置kernel.core_pattern的值，將其設(shè)為sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t。

用gdb進行追蹤

core dump中信息是支持用gdb做調(diào)試的，關(guān)于gdb是linux下一個強大的debug調(diào)試程序，不熟悉的同學，先搜索一下。

用下面的gdb命令打開一個core dump文件：

gdb -c my_core_file

接下來，我們想知道程序崩潰時的堆棧是什么。在gdb提示符下運行bt會給你一個堆棧追蹤。默認情況下，編譯時候沒有做符號調(diào)試，gdb無法加載二進制符號，所以追蹤結(jié)果中會都是??。如下圖所示：

這種情況下，我們需要加載符號符號表，使得顯示正常。可通過在gdb命令下執(zhí)行：

symbol-file 應(yīng)用的執(zhí)行程序（絕對路徑）

sharedlibrary

這會從二進制程序文件及其引入的共享庫中加載符號。執(zhí)行后，再次輸入bt，gdb就會返回帶有行號堆棧跟蹤信息。

如果你想讓其工作正常，在做程序做調(diào)試時候應(yīng)該啟用哦調(diào)試符號編譯（gcc -g）。在試圖找出程序崩潰的原因時，在堆棧跟蹤中有行號非常有用。

在gdb也可以查看每個線程的堆棧，具體方法如下： thread apply all bt full