在 Linux 系統(tǒng)開發(fā)領(lǐng)域中，core dump（核心轉(zhuǎn)儲(chǔ)）是一個(gè)不可或缺的工具，它為我們提供了在程序崩潰時(shí)分析程序狀態(tài)的重要線索。當(dāng)程序因?yàn)槟撤N原因（如段錯(cuò)誤、非法指令等）異常終止時(shí)，Linux 系統(tǒng)會(huì)嘗試將程序在內(nèi)存中的映像、程序計(jì)數(shù)器、寄存器狀態(tài)等信息寫入到一個(gè)名為 core 的文件中，這個(gè)文件就是所謂的 core dump。這個(gè)文件就像是程序崩潰瞬間的 “現(xiàn)場(chǎng)快照”，蘊(yùn)含著大量關(guān)鍵信息。然而，很多人面對(duì)這個(gè)文件卻感到無(wú)從下手，不知道如何從中挖掘出程序崩潰的真正原因。

對(duì)于開發(fā)者而言，core dump 文件如同一塊寶藏，其中蘊(yùn)含著程序崩潰時(shí)的現(xiàn)場(chǎng)信息。通過對(duì) core dump 文件的分析，我們可以了解到程序在崩潰時(shí)的內(nèi)存布局、函數(shù)調(diào)用棧、變量值等重要信息，從而幫助我們快速定位問題原因，優(yōu)化代碼，提高程序的健壯性。別擔(dān)心，今天我們就一起來聊聊 Linux 中的 core dump 分析方法，讓你掌握解讀這個(gè) “程序事故現(xiàn)場(chǎng)報(bào)告” 的技能，在今后遇到程序崩潰問題時(shí)能夠迅速定位問題根源，從容應(yīng)對(duì)。

一、初探 Core Dump

在 Linux 的世界里，Core Dump 是一個(gè)相當(dāng)重要的概念，簡(jiǎn)單來說，它是程序在崩潰時(shí)，操作系統(tǒng)將程序當(dāng)時(shí)的內(nèi)存狀態(tài)、寄存器信息等關(guān)鍵數(shù)據(jù)保存到一個(gè)文件中的過程 ，生成的文件被稱為 Core Dump 文件。這就好比給程序崩潰瞬間拍了一張 “照片”，定格了程序出錯(cuò)那一刻的各種狀態(tài)信息。

當(dāng)程序運(yùn)行過程中遭遇諸如內(nèi)存訪問越界、非法指令、除零錯(cuò)誤等異常情況時(shí)，若沒有對(duì)相應(yīng)的信號(hào)進(jìn)行妥善處理，操作系統(tǒng)就會(huì)觸發(fā) Core Dump 機(jī)制。例如，一個(gè) C 語(yǔ)言程序中出現(xiàn)了訪問空指針的情況，程序就很可能會(huì)產(chǎn)生 Core Dump。

Core Dump 對(duì)于程序調(diào)試和問題定位意義重大。想象一下，在一個(gè)大型項(xiàng)目中，程序可能在復(fù)雜的環(huán)境和條件下運(yùn)行，當(dāng)它突然崩潰時(shí)，要重現(xiàn)崩潰場(chǎng)景往往非常困難。而 Core Dump 文件就像是一份詳細(xì)的事故報(bào)告，無(wú)論崩潰是由于難以捉摸的內(nèi)存問題，還是其他復(fù)雜原因?qū)е碌模渲杏涗浀男畔⒍寄転槲覀兲峁氋F線索，幫助快速定位問題根源，節(jié)省大量的調(diào)試時(shí)間和精力。有了它，開發(fā)者就像是擁有了破案的關(guān)鍵證據(jù)，能夠更高效地修復(fù)程序漏洞，提升軟件的穩(wěn)定性和可靠性。

二、Core Dump生成機(jī)制

2.1觸發(fā)條件解析

在程序運(yùn)行的過程中，多種異常情況會(huì)觸發(fā) Core Dump 。這主要源于特定信號(hào)的產(chǎn)生，當(dāng)程序遭遇這些異常狀況時(shí)，系統(tǒng)會(huì)發(fā)送相應(yīng)信號(hào)，若程序未對(duì)這些信號(hào)進(jìn)行特殊處理，就可能引發(fā) Core Dump。

常見的能觸發(fā) Core Dump 的信號(hào)包括 SIGSEGV、SIGABRT 等。SIGSEGV 信號(hào)通常在程序進(jìn)行非法內(nèi)存訪問時(shí)出現(xiàn)，比如訪問空指針、數(shù)組越界或者使用已經(jīng)釋放的內(nèi)存 。舉例來說，在 C 語(yǔ)言中，如果定義了一個(gè)指針卻未對(duì)其進(jìn)行初始化就直接使用，如char *ptr; *ptr = 'a';，這種訪問空指針的操作極有可能觸發(fā) SIGSEGV 信號(hào)，進(jìn)而導(dǎo)致 Core Dump。

SIGABRT 信號(hào)一般由程序調(diào)用abort函數(shù)引發(fā)，或者在斷言（assert）失敗時(shí)產(chǎn)生。例如，當(dāng)使用assert來檢查某個(gè)條件是否滿足，若條件不成立，就會(huì)觸發(fā) SIGABRT 信號(hào)。像assert(x > 0);，如果此時(shí)x的值不大于 0，就會(huì)產(chǎn)生該信號(hào)。此外，當(dāng)程序出現(xiàn)嚴(yán)重的內(nèi)部錯(cuò)誤，如某些庫(kù)函數(shù)檢測(cè)到非法操作時(shí)，也可能發(fā)送 SIGABRT 信號(hào)，促使系統(tǒng)生成 Core Dump 文件。還有 SIGFPE 信號(hào)，它在發(fā)生致命的算術(shù)運(yùn)算錯(cuò)誤時(shí)發(fā)出，比如除零操作int a = 1 / 0;，就會(huì)觸發(fā)此信號(hào)，進(jìn)而可能引發(fā) Core Dump。

2.2配置要點(diǎn)

在 Linux 系統(tǒng)中，要讓程序在崩潰時(shí)能夠順利生成 Core Dump 文件，需要進(jìn)行相關(guān)配置。其中，ulimit -c命令起著關(guān)鍵作用。默認(rèn)情況下，系統(tǒng)對(duì) Core 文件的大小限制可能為 0，這意味著程序崩潰時(shí)不會(huì)生成 Core 文件。通過ulimit -c命令可以設(shè)置 Core 文件大小的上限 。若要使程序生成不受大小限制的 Core 文件，可以執(zhí)行ulimit -c unlimited命令。例如，在終端中輸入該命令后，再運(yùn)行可能會(huì)崩潰的程序，若程序發(fā)生異常，就更有可能生成完整的 Core Dump 文件。

要確保程序崩潰時(shí)能成功生成 Core 文件，還需滿足其他條件。首先，程序運(yùn)行的當(dāng)前目錄必須對(duì)進(jìn)程具有寫權(quán)限，否則無(wú)法將 Core 文件保存到該目錄。其次，如果程序在運(yùn)行過程中調(diào)用了seteuid()或setegid()函數(shù)來改變進(jìn)程的有效用戶 ID 或組 ID ，默認(rèn)情況下系統(tǒng)不會(huì)為這類進(jìn)程生成 Core 文件。此時(shí)，需要將/proc/sys/fs/suid_dumpable文件的內(nèi)容修改為 1，才能夠讓這類進(jìn)程在崩潰時(shí)生成 Core 文件。此外，還可以通過修改/proc/sys/kernel/core_pattern文件來指定 Core 文件的生成路徑和命名規(guī)則，從而更好地管理生成的 Core Dump 文件，方便后續(xù)的調(diào)試工作。

三、引起Core Dump的 “元兇 ”盤點(diǎn)

C/C++ 程序員遇到的比較常見的一個(gè)問題，就是自己編寫的代碼， 在運(yùn)行過程中出現(xiàn)了意想不到的 core dump。程序發(fā)生 core dump 的原因是多方面的，不同的 core dump 問題有著不同的解決辦法。

同時(shí)，不同的 core dump 問題解決的難易程度也存在很大的區(qū)別。有些在短短幾秒鐘內(nèi)就可以定位問題，但是也有一些可能需要花費(fèi)數(shù)天時(shí)間才能解決。這種問題是對(duì)軟件開發(fā)人員的極大的挑戰(zhàn)。筆者從事 C/C++ 語(yǔ)言的軟件開發(fā)工作多年，前后解決了許多此類問題，久而久之積累了一定的經(jīng)驗(yàn)，現(xiàn)把常見 core dump 總結(jié)一下。

3.1指針惹的禍

在 C 和 C++ 語(yǔ)言的編程世界里，指針無(wú)疑是一把威力強(qiáng)大卻又暗藏危險(xiǎn)的 “雙刃劍”。空指針、野指針和懸空指針的出現(xiàn)，常常是導(dǎo)致 Core Dump 的重要原因。

空指針，簡(jiǎn)單來說，就是指向地址為 0 的指針。當(dāng)程序嘗試對(duì)空指針進(jìn)行解引用操作，比如讀取或?qū)懭肟罩羔標(biāo)赶虻膬?nèi)存位置時(shí)，就如同試圖在一個(gè)不存在的房間里存放或取走物品，必然會(huì)引發(fā)程序的異常，進(jìn)而導(dǎo)致 Core Dump。例如：

#include <stdio.h>
int main() {
    int *ptr = NULL;
    *ptr = 10; // 嘗試對(duì)空指針解引用，這會(huì)導(dǎo)致Core Dump
    return 0;
}

在這段代碼中，ptr被初始化為NULL，而后試圖向ptr所指向的內(nèi)存位置寫入值 10，這是不被允許的，運(yùn)行該程序大概率會(huì)觸發(fā) Core Dump 。

野指針，是那些未經(jīng)初始化就直接使用的指針，或者是指針?biāo)赶虻膬?nèi)存已經(jīng)被釋放，但指針的值卻沒有被置為NULL的情況。例如：

#include <stdio.h>
#include <stdlib.h>
int main() {
    int *ptr;
    *ptr = 10; // 未初始化就使用，這是野指針的典型情況，會(huì)導(dǎo)致Core Dump
    free(ptr);
    ptr = NULL;
    return 0;
}

在這個(gè)例子中，ptr沒有被初始化就進(jìn)行賦值操作，這是非常危險(xiǎn)的，很可能引發(fā) Core Dump。另外，在釋放內(nèi)存后，及時(shí)將指針置為NULL是良好的編程習(xí)慣，否則就可能產(chǎn)生野指針問題。

懸空指針，通常是在指針?biāo)赶虻膬?nèi)存被釋放后，沒有對(duì)指針進(jìn)行相應(yīng)處理，導(dǎo)致指針仍然指向那塊已經(jīng)無(wú)效的內(nèi)存區(qū)域。例如：

#include <stdio.h>
#include <stdlib.h>
int main() {
    int *ptr = (int *)malloc(sizeof(int));
    *ptr = 10;
    free(ptr);
    *ptr = 20; // 這里ptr成為懸空指針，對(duì)其操作會(huì)導(dǎo)致Core Dump
    return 0;
}

在這段代碼中，ptr指向的內(nèi)存被free釋放后，ptr成為懸空指針，此時(shí)再對(duì)其進(jìn)行賦值操作，就如同在一塊已經(jīng)被收回的土地上繼續(xù)建造房屋，會(huì)引發(fā)程序的崩潰，產(chǎn)生 Core Dump。

3.2數(shù)組與指針越界

數(shù)組越界和指針越界也是引發(fā) Core Dump 的常見原因。數(shù)組越界，指的是訪問數(shù)組時(shí)使用的下標(biāo)超出了數(shù)組定義的有效范圍。比如，定義了一個(gè)包含 5 個(gè)元素的數(shù)組int arr[5]，若嘗試訪問arr[5]或arr[6]等，就會(huì)發(fā)生數(shù)組越界。這就好比在一個(gè)只有 5 個(gè)房間的公寓里，卻試圖進(jìn)入第 6 個(gè)房間，顯然是不合法的。

指針越界，則是指針指向了不屬于它應(yīng)該訪問的內(nèi)存區(qū)域。例如，通過指針?biāo)阈g(shù)運(yùn)算使指針超出了原本分配的內(nèi)存范圍。

曾經(jīng)有一道百度的面試題，其代碼如下：

#include <stdio.h>
int main() {
    int i;
    int array[6];
    for (i = 0; i < 8; i++) {
        array[i] = 0;
        printf("Grayson Zheng\n");
    }
    return 0;
}

在這段代碼中，array數(shù)組只定義了 6 個(gè)元素，但循環(huán)卻試圖訪問array[7]，這必然會(huì)導(dǎo)致數(shù)組越界。在 Linux 系統(tǒng)下運(yùn)行該程序，在打印 8 次 “Grayson Zheng” 后，程序就會(huì)因?yàn)閿?shù)組越界而發(fā)生 Core Dump。這生動(dòng)地展示了數(shù)組越界帶來的嚴(yán)重后果，提醒開發(fā)者在編寫代碼時(shí)，務(wù)必仔細(xì)檢查數(shù)組的訪問邊界，避免此類錯(cuò)誤的發(fā)生。

3.3數(shù)據(jù)競(jìng)爭(zhēng)及代碼不規(guī)范

在多線程編程的環(huán)境中，數(shù)據(jù)競(jìng)爭(zhēng)是一個(gè)不容忽視的問題，它也常常是導(dǎo)致 Core Dump 的 “元兇” 之一。當(dāng)多個(gè)線程同時(shí)訪問和修改共享數(shù)據(jù)，而沒有采取適當(dāng)?shù)耐綑C(jī)制時(shí)，就會(huì)引發(fā)數(shù)據(jù)競(jìng)爭(zhēng)。這就好比多個(gè)廚師在沒有協(xié)調(diào)的情況下，同時(shí)對(duì)同一道菜進(jìn)行烹飪操作，很容易導(dǎo)致混亂和錯(cuò)誤。

競(jìng)態(tài)條件是指兩個(gè)或多個(gè)線程同時(shí)訪問共享數(shù)據(jù)，并且至少有一個(gè)線程在修改數(shù)據(jù)時(shí)未進(jìn)行適當(dāng)?shù)耐?。這可能導(dǎo)致以下問題：

1. 數(shù)據(jù)不一致：多個(gè)線程讀取和修改全局變量時(shí)，可能會(huì)導(dǎo)致數(shù)據(jù)處于不一致的狀態(tài)。

2. 程序崩潰：未同步的訪問可能導(dǎo)致非法的內(nèi)存訪問，從而引發(fā)段錯(cuò)誤（segmentation fault），導(dǎo)致程序崩潰并生成核心轉(zhuǎn)儲(chǔ)文件。

此外，代碼中的邏輯錯(cuò)誤、對(duì)函數(shù)的不當(dāng)調(diào)用等不規(guī)范的代碼編寫方式，也可能導(dǎo)致 Core Dump。比如，調(diào)用某個(gè)函數(shù)時(shí)，傳入了不符合函數(shù)要求的參數(shù)，導(dǎo)致函數(shù)內(nèi)部進(jìn)行了非法的內(nèi)存訪問或其他錯(cuò)誤操作。假設(shè)一個(gè)函數(shù)期望接收一個(gè)指向有效內(nèi)存區(qū)域的指針，但實(shí)際傳入的是一個(gè)空指針，這就很可能引發(fā)程序崩潰，產(chǎn)生 Core Dump。因此，在編寫代碼時(shí)，開發(fā)者需要嚴(yán)格遵循代碼規(guī)范，仔細(xì)檢查函數(shù)的參數(shù)傳遞和邏輯流程，減少因代碼不規(guī)范而引發(fā) Core Dump 的風(fēng)險(xiǎn)。

四、Core Dump分析實(shí)戰(zhàn)利器——GDB

4.1啟用 core dump

默認(rèn)情況下，程序運(yùn)行崩潰導(dǎo)致 core dump，是不會(huì)生成 core 文件的，因?yàn)橄到y(tǒng)的 RLIMIT_CORE（核心文件大?。┵Y源限制，默認(rèn)情況下設(shè)置為 0。

使用 ulimit -c 命令可以查看 core 文件的大小，其中 -c 的含義是 core file size，單位是 blocks 也就是 KB 的意思。ulimit -c 命令后面可以寫整數(shù)，表示生成寫入值大小的 core 文件。如果使用 ulimit -c unlimited 設(shè)置無(wú)限大，則任意情況下都會(huì)產(chǎn)生 core 文件。

以下命令可在用戶進(jìn)程觸發(fā)信號(hào)時(shí)啟用 core dump 生成，并使用合理的名稱將核心文件位置設(shè)置為 /tmp/。請(qǐng)注意，這些設(shè)置不會(huì)永久存儲(chǔ)。

ulimit -c unlimited
echo 1 > /proc/sys/kernel/core_uses_pid
echo "/tmp/core-%e-%s-%u-%g-%p-%t" > /proc/sys/kernel/core_pattern

[!IMPORTANT]后面兩條命令在運(yùn)行時(shí)，即使是加了 sudo 執(zhí)行，也可能會(huì)被提示權(quán)限不足。這可能是由于 shell 的重定向在命令前已經(jīng)處理完成，因此重定向操作并沒有被提升到超級(jí)用戶權(quán)限，這就導(dǎo)致了 “Permission denied” 的錯(cuò)誤。可以通過以下命令來解決這個(gè)問題：echo 1 | sudo tee /proc/sys/kernel/core_uses_pidecho "/tmp/core-%e-%s-%u-%g-%p-%t" | sudo tee /proc/sys/kernel/core_pattern

順便解釋一下 "/tmp/core-%e-%s-%u-%g-%p-%t" 的各個(gè)參數(shù)的含義：

? %e：導(dǎo)致 core dump 的程序的可執(zhí)行文件名。

? %s：導(dǎo)致 core dump 的信號(hào)編號(hào)。

? %u：導(dǎo)致 core dump 的程序的實(shí)際用戶 ID。

? %g：導(dǎo)致 core dump 的程序的實(shí)際組 ID。

? %p：導(dǎo)致 core dump 的程序的進(jìn)程 ID。

? %t：core dump 發(fā)生時(shí)的時(shí)間戳（自 epoch 時(shí)間以來的秒數(shù)）。

因此，/tmp/core-%e-%s-%u-%g-%p-%t 會(huì)生成包含如下信息的 core 文件：

/tmp/core-<executable>-<signal>-<uid>-<gid>-<pid>-<timestamp>

舉個(gè)例子，如果一個(gè)進(jìn)程名為 my_program，用戶 ID 為 1000，組 ID 為 1000，進(jìn)程 ID 為 12345，并且在 1617701234 時(shí)間點(diǎn)崩潰于信號(hào) 11，則生成的 core 文件名將是：

/tmp/core-my_program-11-1000-1000-12345-1617701234

4.2觸發(fā) core dump

我們使用兩個(gè)簡(jiǎn)單的 C 程序作為示例。

⑴因空指針解引用而崩潰

文件名為 example.c：

#include <stdio.h>

voidfunc()
{
int*p =NULL;
*p =13;
}

intmain()
{
    func();
return0;
}

編譯并運(yùn)行程序：

gcc -g -o example example.c
./example

運(yùn)行程序時(shí)后，會(huì)在 /tmp/ 文件夾下生成一個(gè) core 文件。

圖片

⑵通過 SIGSEGV 信號(hào)觸發(fā) core dump

文件名為 example2.c：

#include <stdio.h>
#include <unistd.h>

int global_num;

intmain()
{
while(1){
printf("global_num = %d\n", global_num++);
        sleep(1);
}

return0;
}

編譯并運(yùn)行程序：

gcc -g -o example2 example2.c
./example2

運(yùn)行程序時(shí)后，在另一個(gè)終端查找進(jìn)程的 PID，并用 kill -11 加上 PID，向進(jìn)程發(fā)送段錯(cuò)誤信號(hào)，結(jié)束掉進(jìn)程。之后會(huì)在 /tmp/ 文件夾下生成一個(gè) core 文件。

圖片

4.3GDB 加載 Core Dump 文件

在 Linux 系統(tǒng)中，GDB（GNU Debugger）是一款強(qiáng)大的調(diào)試工具，在分析 Core Dump 文件時(shí)發(fā)揮著關(guān)鍵作用。使用 GDB 加載可執(zhí)行文件和 Core Dump 文件的操作相對(duì)簡(jiǎn)單。假設(shè)我們有一個(gè)名為my_program的可執(zhí)行文件，以及對(duì)應(yīng)的 Core Dump 文件core.1234（這里的1234為進(jìn)程 ID，實(shí)際使用時(shí)需根據(jù)具體情況替換），在終端中輸入以下命令即可啟動(dòng) GDB 并加載相關(guān)文件：

gdb my_program core.1234

執(zhí)行該命令后，GDB 會(huì)自動(dòng)加載可執(zhí)行文件和 Core Dump 文件，并停留在程序崩潰時(shí)的位置。此時(shí)，我們就可以利用 GDB 提供的各種命令對(duì) Core Dump 進(jìn)行深入分析，探尋程序崩潰的原因。

⑴關(guān)鍵調(diào)試命令解析

①where/bt—— 查看堆棧信息

在 GDB 中，where和bt（backtrace 的縮寫）命令功能相近，主要用于查看當(dāng)前線程的函數(shù)調(diào)用堆棧信息。這就像是沿著程序崩潰時(shí)的 “足跡”，一步步回溯到程序的入口點(diǎn)，幫助我們清晰地了解程序執(zhí)行的路徑，從而找到問題所在。

當(dāng)程序崩潰時(shí)，使用bt命令，GDB 會(huì)輸出函數(shù)調(diào)用的序列，每一行都包含了函數(shù)名、所在文件以及行號(hào)等重要信息。例如：

(gdb) bt
#0  func3 (arg1=0x7fffffffde10, arg2=42) at my_file.c:123
#1  0x00005555555552b5 in func2 (arg=0x7fffffffde10) at main.c:234
#2  0x0000555555555350 in main () at main.c:345

從上述輸出中可以看出，程序崩潰時(shí)正在執(zhí)行func3函數(shù)，該函數(shù)位于my_file.c文件的第 123 行，而func3是由func2調(diào)用的，func2又在main函數(shù)中被調(diào)用。通過這樣的堆棧信息，我們能夠快速定位到程序崩潰的大致位置，進(jìn)而深入分析問題。

②p—— 查看變量值

p（print 的縮寫）命令用于打印變量的值，這在分析 Core Dump 時(shí)非常實(shí)用。通過查看變量在程序崩潰時(shí)的值，可以判斷程序的運(yùn)行狀態(tài)是否符合預(yù)期，從而發(fā)現(xiàn)潛在的問題。

例如，我們懷疑某個(gè)變量在程序崩潰時(shí)的值異常，可使用p命令查看其值。假設(shè)我們要查看變量my_variable的值，在 GDB 中輸入：

(gdb) p my_variable

GDB 會(huì)輸出my_variable的值。如果該變量是一個(gè)復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，如結(jié)構(gòu)體或數(shù)組，p命令也能以相應(yīng)的格式展示其內(nèi)容。例如，對(duì)于一個(gè)結(jié)構(gòu)體變量my_struct，輸入p my_struct，GDB 會(huì)顯示結(jié)構(gòu)體中各個(gè)成員的值。這有助于我們?nèi)媪私獬绦虮罎r(shí)變量的狀態(tài)，為問題排查提供有力支持。

③ info registers—— 查看寄存器信息

info registers命令用于顯示當(dāng)前寄存器的內(nèi)容。寄存器是 CPU 中用于臨時(shí)存儲(chǔ)數(shù)據(jù)的高速存儲(chǔ)單元，程序運(yùn)行過程中的各種數(shù)據(jù)處理和指令執(zhí)行都與寄存器密切相關(guān)。通過查看寄存器在程序崩潰時(shí)的狀態(tài)，我們可以獲取更多關(guān)于程序運(yùn)行的底層信息，這對(duì)于深入分析程序崩潰原因至關(guān)重要。

在 GDB 中輸入info registers，會(huì)輸出一系列寄存器及其對(duì)應(yīng)的值。例如：

(gdb) info registers
rax            0x0      0
rbx            0x7ffff7fc1a40   140737351884352
rcx            0x1      1
rdx            0x7ffff7bc8723   140737351871779
...

這些寄存器的值反映了程序崩潰瞬間 CPU 的工作狀態(tài)，結(jié)合其他調(diào)試信息，能夠幫助我們更全面地理解程序崩潰的原因，尤其是在涉及到硬件相關(guān)的問題時(shí)，寄存器信息的分析尤為重要。

五、實(shí)戰(zhàn)案例深度剖析

5.1簡(jiǎn)單案例分析

下面通過一個(gè)簡(jiǎn)單的代碼示例，來看看如何利用 GDB 對(duì) Core Dump 進(jìn)行分析。假設(shè)有如下一段 C 語(yǔ)言代碼：

#include <stdio.h>
#include <stdlib.h>

void func() {
    int *ptr = NULL;
    *ptr = 10; // 這里會(huì)導(dǎo)致空指針解引用，引發(fā)Core Dump
}

int main() {
    func();
    return 0;
}

在上述代碼中，func函數(shù)內(nèi)定義了一個(gè)空指針ptr，并嘗試對(duì)其進(jìn)行解引用操作，這必然會(huì)引發(fā)程序崩潰。為了讓 GDB 能夠更好地分析問題，在編譯時(shí)需要加上-g選項(xiàng)，以生成調(diào)試信息。編譯命令如下：

gcc -g -o test test.c

運(yùn)行該程序后，程序會(huì)因?yàn)榭罩羔樈庖枚罎ⅲ⑸?Core Dump 文件（前提是已正確配置 Core Dump 生成，如設(shè)置ulimit -c unlimited）。假設(shè)生成的 Core Dump 文件名為core.12345（12345為進(jìn)程 ID）。

接下來，使用 GDB 加載可執(zhí)行文件和 Core Dump 文件進(jìn)行分析：

gdb test core.12345

進(jìn)入 GDB 環(huán)境后，使用bt命令查看堆棧信息：

(gdb) bt
#0  func () at test.c:5
#1  0x0000555555555199 in main () at test.c:9

從輸出結(jié)果可以清晰地看到，程序在test.c文件的第 5 行發(fā)生崩潰，此時(shí)正在執(zhí)行func函數(shù)，而func函數(shù)是由main函數(shù)調(diào)用的。再使用p命令查看ptr變量的值：

(gdb) p ptr
$1 = (int *) 0x0

由此可知，ptr確實(shí)是一個(gè)空指針，這就是導(dǎo)致程序崩潰并產(chǎn)生 Core Dump 的原因。通過這個(gè)簡(jiǎn)單的案例，我們初步領(lǐng)略了 GDB 在分析 Core Dump 文件時(shí)的強(qiáng)大功能，它能夠快速準(zhǔn)確地定位到問題所在，為開發(fā)者節(jié)省大量的調(diào)試時(shí)間。

5.2復(fù)雜場(chǎng)景實(shí)戰(zhàn)

在實(shí)際的項(xiàng)目開發(fā)中，多線程程序的 Core Dump 問題往往更加復(fù)雜和難以排查。下面分享一個(gè)多線程程序出現(xiàn) Core Dump 的案例，以及如何運(yùn)用 GDB 及多線程調(diào)試命令來解決問題。

假設(shè)有一個(gè)多線程程序，其功能是多個(gè)線程同時(shí)對(duì)一個(gè)共享數(shù)組進(jìn)行讀寫操作。部分代碼如下：

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

#define ARRAY_SIZE 100
int shared_array[ARRAY_SIZE];
pthread_mutex_t mutex;

void *write_thread(void *arg) {
    for (int i = 0; i < ARRAY_SIZE; i++) {
        pthread_mutex_lock(&mutex);
        shared_array[i] = i;
        pthread_mutex_unlock(&mutex);
    }
    return NULL;
}

void *read_thread(void *arg) {
    for (int i = 0; i < ARRAY_SIZE; i++) {
        pthread_mutex_lock(&mutex);
        int value = shared_array[i];
        printf("Read value: %d at index %d\n", value, i);
        pthread_mutex_unlock(&mutex);
    }
    return NULL;
}

int main() {
    pthread_t write_tid, read_tid;
    pthread_mutex_init(&mutex, NULL);

    if (pthread_create(&write_tid, NULL, write_thread, NULL)!= 0) {
        perror("Failed to create write thread");
        return 1;
    }
    if (pthread_create(&read_tid, NULL, read_thread, NULL)!= 0) {
        perror("Failed to create read thread");
        return 1;
    }

    if (pthread_join(write_tid, NULL)!= 0) {
        perror("Failed to join write thread");
        return 1;
    }
    if (pthread_join(read_tid, NULL)!= 0) {
        perror("Failed to join read thread");
        return 1;
    }

    pthread_mutex_destroy(&mutex);
    return 0;
}

在這個(gè)程序中，我們創(chuàng)建了一個(gè)寫線程和一個(gè)讀線程，它們通過互斥鎖mutex來保證對(duì)共享數(shù)組shared_array的安全訪問。然而，在實(shí)際運(yùn)行過程中，程序偶爾會(huì)出現(xiàn) Core Dump 現(xiàn)象。

為了調(diào)試這個(gè)問題，首先確保在編譯時(shí)加上-g選項(xiàng)，以生成調(diào)試信息：

gcc -g -o multi_thread_test multi_thread_test.c -lpthread

運(yùn)行程序后，當(dāng) Core Dump 發(fā)生時(shí)，假設(shè)生成的 Core Dump 文件名為core.67890。使用 GDB 加載可執(zhí)行文件和 Core Dump 文件：

gdb multi_thread_test core.67890

進(jìn)入 GDB 環(huán)境后，首先使用info threads命令查看所有線程的信息：

(gdb) info threads
  Id   Target Id         Frame
  1    Thread 0x7ffff7fda700 (LWP 67890) "multi_thread_test" main () at multi_thread_test.c:32
  2    Thread 0x7ffff77ef700 (LWP 67891) "multi_thread_test" read_thread (arg=0x0) at multi_thread_test.c:18
  3    Thread 0x7ffff6fee700 (LWP 67892) "multi_thread_test" write_thread (arg=0x0) at multi_thread_test.c:10

從輸出結(jié)果可以看到，程序中有三個(gè)線程，其中線程 1 是主線程，線程 2 是讀線程，線程 3 是寫線程。接下來，我們需要切換到發(fā)生問題的線程進(jìn)行分析。假設(shè)通過觀察，發(fā)現(xiàn)線程 2 在讀取共享數(shù)組時(shí)出現(xiàn)了 Core Dump。使用thread 2命令切換到線程 2：

(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff77ef700 (LWP 67891))]
#0  read_thread (arg=0x0) at multi_thread_test.c:20

此時(shí)，我們已經(jīng)切換到讀線程，并且 GDB 停在了讀線程發(fā)生問題的代碼行。使用bt命令查看讀線程的堆棧信息：

(gdb) bt
#0  read_thread (arg=0x0) at multi_thread_test.c:20
#1  0x00007ffff7bc8723 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00005555555552b5 in main () at multi_thread_test.c:28

從堆棧信息可以看出，讀線程在執(zhí)行pthread_mutex_lock函數(shù)時(shí)出現(xiàn)了問題。進(jìn)一步使用p命令查看相關(guān)變量的值，例如查看i的值：

(gdb) p i
$1 = 120

發(fā)現(xiàn)i的值超出了共享數(shù)組的邊界ARRAY_SIZE（這里ARRAY_SIZE為 100），這就是導(dǎo)致 Core Dump 的原因。原來是在多線程環(huán)境下，由于線程調(diào)度的不確定性，讀線程在寫線程尚未完全初始化共享數(shù)組時(shí)，就嘗試讀取了越界的位置，從而引發(fā)了錯(cuò)誤。通過這個(gè)復(fù)雜場(chǎng)景的實(shí)戰(zhàn)案例，我們可以看到，在多線程程序中，利用 GDB 的多線程調(diào)試命令，能夠逐步排查出 Core Dump 的根源，為解決復(fù)雜的多線程問題提供了有力的手段。

六、全文總結(jié)

Core Dump 分析在 Linux 程序開發(fā)與調(diào)試中扮演著舉足輕重的角色。通過深入了解 Core Dump 的生成機(jī)制，我們能夠精準(zhǔn)地捕捉程序崩潰瞬間的關(guān)鍵信息，為后續(xù)的問題排查工作奠定堅(jiān)實(shí)基礎(chǔ)。

在實(shí)際的開發(fā)過程中，無(wú)論是指針操作不當(dāng)、數(shù)組越界，還是多線程環(huán)境下的數(shù)據(jù)競(jìng)爭(zhēng)等問題，都可能引發(fā) Core Dump 。而 GDB 作為一款強(qiáng)大的調(diào)試工具，為我們提供了高效分析 Core Dump 文件的有力手段，借助where、bt、p、info registers等一系列實(shí)用命令，我們能夠快速定位問題根源，大幅提升調(diào)試效率。

為了進(jìn)一步提升 Core Dump 分析能力，建議讀者深入學(xué)習(xí) GDB 的高級(jí)特性，如設(shè)置斷點(diǎn)、觀察變量變化、進(jìn)行反匯編分析等。同時(shí)，對(duì)于多線程程序的調(diào)試，掌握更多關(guān)于線程同步、互斥機(jī)制的知識(shí)，有助于更深入地理解和解決多線程環(huán)境下的 Core Dump 問題。此外，還可以關(guān)注其他相關(guān)的調(diào)試工具和技術(shù)，如 Valgrind、perf 等，它們?cè)跈z測(cè)內(nèi)存泄漏、性能分析等方面具有獨(dú)特優(yōu)勢(shì)，與 Core Dump 分析相結(jié)合，能夠?yàn)槌绦虻姆€(wěn)定性和性能優(yōu)化提供全方位的支持。希望大家在今后的編程實(shí)踐中，充分運(yùn)用 Core Dump 分析方法，不斷提升自己解決問題的能力，編寫出更加健壯、可靠的程序。