[[415779]]

本文轉載自微信公眾號「Linux內核那些事」，作者songsong001。轉載本文請聯系Linux內核那些事公眾號。

人都會犯錯，所以在編寫程序時難免會出現 BUG。

有些 BUG 是業務邏輯上的錯誤導致的，一般不會導致程序崩潰，例如：原本要將兩個數相加，但不小心把這兩個數相減，而導致結果出錯。這時我們可以通過在程序中，使用 printf 這類輸出函數來進行打點調試。

但有些 BUG 是由于某些致命的操作而導致的，一般會導致程序崩潰，例如：訪問未經申請的內存地址。由于程序會異常退出，所以一般不能通過 printf 這類輸出函數進行打點調試。

另外，對于必現的 BUG (就是不管什么條件都會發生)，一般可以通過 GDB 設置斷點進行調試。但對于偶現的 BUG，由于在某些特定的條件下才會發生，所以比較難直接通過 GDB 進行調試。

那么，這時可以通過 Linux 提供的 coredump 文件進行調試。

一、coredump 文件生成過程

在程序發生某些錯誤而導致進程異常退出時，Linux 內核會根據進程當時的內存信息，生成一個 coredump 文件。而 GDB 可以通過這個 coredump 文件重現當時導致進程異常退出的場景，并且可以通過 GDB 來找到導致進程異常退出的原因。

當進程接收到某些 信號 而導致異常退出時，就會生成 coredump 文件。那么，哪些信號會導致生成 coredump 文件呢?

會導致生成 coredump 文件的信號，如下表所示：

下面我們通過一個例子來說明怎么生成 coredump 文件。

從上面的表格可知，當進程接收到 SIGSEGV 信號時會生成 coredump 文件。SIGSEGV 信號是當進程訪問錯誤(未經申請)內存地址時觸發的，所以下面我們編寫一個訪問錯誤內存地址的程序：

int main(int argc, char *argv[]) 
{ 
    char *addr = (char *)0; // 設置 addr 變量為內存地址 "0" 
 
    *addr = '\0';           // 向內存地址 "0" 寫入數據 
 
    return 0; 
} 

在上面的例子中，由于內存地址 ”0“ 并沒有通過調用 malloc 函數申請，所以當向地址 ”0“ 寫入數據時將會導致 段錯誤，進程將會接收到 SIGSEGV 信號。

當進程接收到 SIGSEGV 信號后，內核將會根據進程當時的內存信息生成 coredump 文件，并且把進程殺死。

我們將上面的程序編譯并且運行后，會發現程序異常退出，并且生成一個名為 core.xxx 的文件，這個文件就是 coredump 文件。如下圖所示：

注意：

• 編譯的時候記得加上 -g 參數表示保留調試信息，否則使用 GDB 調試時會找不到函數名或者變量名。
• 如果沒有生成 coredump 文件的話，一般是受到資源限制，先使用命令 ulimit -c unlimited 設置資源不受限制。

coredump 文件點后面的數字是進程的 PID。

現在我們只需要輸入如下命令，即可使用 GDB 配合 coredump 文件來調試程序了：

$ gdb ./coredump ./core.6359 

GDB 運行后會停止在發生異常的代碼處，并且將發生異常的代碼打印出來，如下圖：

從上面的輸出可以看到，GDB 除了會將發生異常的代碼打印到終端外，還會將其所在的函數、文件名和所在文件的行數也打印出來，這樣我們就很快能定位到哪行代碼導致異常的。

二、coredump文件生成原理

前面介紹過，當進程接收到某些 信號 而導致異常退出時，就會生成 coredump 文件。

當進程從 內核態 返回到 用戶態 前，內核會查看進程的信號隊列中是否有信號沒有處理，如果有就調用 do_signal 內核函數處理信號。我們可以通過下圖來展示內核是怎么生成 coredump 文件的：

進程從內核態返回到用戶態的地方有很多，如 從系統調用返回、從硬中斷處理程序返回 和 從進程調度程序返回 等。上圖主要通過 從進程調度程序返回 作為示例，來展示內核是怎么生成 coredump 文件的。

下面我們來分析一下 coredump 文件生成過程的步驟：

1. 信號處理 do_signal()

當進程從內核態返回到用戶態前，內核會查看進程的信號隊列中是否有信號沒有被處理，如果有就調用 do_signal 內核函數處理信號。我們來看看 do_signal 函數的實現：

static void fastcall do_signal(struct pt_regs *regs) 
{ 
    siginfo_t info; 
    int signr; 
    struct k_sigaction ka; 
    sigset_t *oldset; 
 
    ... 
    signr = get_signal_to_deliver(&info, &ka, regs, NULL); 
    ... 
} 

上面代碼去掉了很多與生成 coredump 文件無關的邏輯，最終我們可以看到，do_signal 函數主要調用 get_signal_to_deliver 內核函數來進行進一步的處理。

get_signal_to_deliver 內核函數的主要工作是從進程的信號隊列中獲取一個信號，然后根據信號的類型來進行不同的操作。我們主要關注生成 coredump 文件相關的邏輯，如下代碼：

int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, 
                          struct pt_regs *regs, void *cookie) 
{ 
    sigset_t *mask = &current->blocked; 
    int signr = 0; 
 
    ... 
    for (;;) { 
        ... 
        // 1. 從進程信號隊列中獲取一個信號 
        signr = dequeue_signal(current, mask, info);  
 
        ... 
        // 2. 判斷是否會生成 coredump 文件的信號 
        if (sig_kernel_coredump(signr)) { 
            // 3. 調用 do_coredump() 函數生成 coredump 文件 
            do_coredump((long)signr, signr, regs); 
        } 
        ... 
    } 
    ... 
} 

上面代碼去掉了與生成 coredump 文件無關的邏輯，最后我們可以看到 get_signal_to_deliver 函數主要完成三個工作：

調用 dequeue_signal 函數從進程的信號隊列中獲取一個信號。

調用 sig_kernel_coredump 函數判斷信號是否會生成 coredump 文件。

如果信號會生成 coredump 文件，那么就調用 do_coredump 函數生成 coredump 文件。

2. 生成 coredump 文件

如果要處理的信號會觸發生成 coredump 文件，那么內核就會調用 do_coredump 函數來生成 coredump 文件。do_coredump 函數的實現如下：

int do_coredump(long signr, int exit_code, struct pt_regs *regs) 
{ 
    char corename[CORENAME_MAX_SIZE + 1]; 
    struct mm_struct *mm = current->mm; 
    struct linux_binfmt *binfmt; 
    struct inode *inode; 
    struct file *file; 
    int retval = 0; 
    int fsuid = current->fsuid; 
    int flag = 0; 
    int ispipe = 0; 
 
    binfmt = current->binfmt; // 當前進程所使用的可執行文件格式（如ELF格式） 
 
    ... 
    // 1. 判斷當前進程可生成的 coredump 文件大小是否受到資源限制 
    if (current->signal->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump) 
        goto fail_unlock; 
 
    ... 
    // 2. 生成 coredump 文件名 
    ispipe = format_corename(corename, core_pattern, signr); 
 
    ... 
    // 3. 創建 coredump 文件 
    file = filp_open(corename, O_CREAT|2|O_NOFOLLOW|O_LARGEFILE|flag, 0600); 
 
    ... 
    // 4. 把進程的內存信息寫入到 coredump 文件中 
    retval = binfmt->core_dump(signr, regs, file); 
 
fail_unlock: 
    ... 
    return retval; 
} 

經過代碼精簡后，最終可以看到 do_coredump 函數完成四個工作：

• 判斷當前進程可生成的 coredump 文件大小是否受到資源限制。
• 如果不受限制，那么調用 format_corename 函數生成 coredump 文件的文件名。
• 接著調用 filp_open 函數創建 coredump 文件。
• 最后根據當前進程所使用的可執行文件格式來選擇相應的填充方法來填充 coredump 文件的內容，對于 ELF文件格式 使用的是 elf_core_dump 方法。

elf_core_dump 方法的主要工作是：把進程的內存信息和內容寫入到 coredump 文件中，并且以 ELF文件格式 作為 coredump 文件的存儲格式。有興趣的可以自行閱讀 elf_core_dump 方法的代碼，這里就不作進一步的解說了。

三、生產環境應該打開 coredump 功能嗎?

最后，我們來討論一下在生產環境應不應該打開 coredump 功能。

筆者遇過在生產環境打開 coredump 功能而導致的事故，故事如下：

我們上線了一個有 BUG 的 WEB 服務，這個程序是以 master-worker 模式運行的。master 進程的主要工作是監控 worker 進程的運行情況，如果 worker 進程掛掉，master 進程會創建新的 worker 進程來繼續工作。

由于 worker 進程的代碼存在漏洞，會導致 worker 進程訪問非法的內存地址而產生 SIGSEGV 信號(段錯誤)，而 SIGSEGV 信號會觸發生成 coredump 文件。

由于每次 worker 進程異常退出后，master 進程都會創建新的 worker 進程來補充，所以最終導致 worker 進程不斷的異常退出和被創建。這樣就不斷的生成 coredump 文件，最終導致磁盤被打滿。

所以，經過上面的事故，我建議大家不要在生成環境打開 coredump 功能。那么，如果程序有問題怎么排查呢?

我的建議是摘掉線上的某一臺機器，打開 coredump 功能，然后模擬發生異常的情況來進行排查。如果人工比較難模擬，那么可以通過使用 tcpcopy 這些工具來把線上的流量導入到調試機器進行調試。生成 coredump 文件后，可以使用 GDB 來進行調試。