閑話

最近分析問題時，發現我的環境中，經常有用戶態進程異常退出，但是卻沒有core文件生成，簡單看了一下相關的內核流程，mark一下。

Core Dump基本原理

當應用程序在用戶態發生異常時，比如常見的段錯誤，通常會生成core文件，通過gdb分析core文件，基本就能定位問題。

core文件實際是當前進程地址空間的一個鏡像文件，其中包含了該進程在內存中的所有信息。

Linux系統中，Core Dump的主要流程描述為：

進程運行過程中出現異常(比如段錯誤)，該異常為硬件上報，可理解為一個中斷，異常上報后，CPU在執行完當前的指令后會立刻停止執行當前上下文中的指令，而進入異常處理流程：常規的保存上下文，跳轉到相應的中斷向量處執行等，具體不詳述了。

進入異常處理流程后，會判斷發生異常的CPU模式(X86中對應相應的Ring)，如果發生異常時，處于用戶態，則說明該異常只會影響當前進程，于是向用戶態進程發送相應的信號，如果是段錯誤，發送的信號為SIGSEGV,如果為Aborts，通常發送的信號為SIGBUS。如果發生異常時處于內核態，則說明該異常對系統是致命的，則會進入內核die流程，最終會panic，這種情況不會生成core文件，不是這里討論的重點。

當用戶態進程有處理信號的時機時(比如得到調度)，其會檢查pending的信號，然后進行處理，如果發現pending的信號為SIG_KERNEL_COREDUMP_MASK中的一個，則會進入core文件搜集流程，最終根據用戶配置生成core文件。

代碼分析

這里以ARM64架構中，非對齊異常的流程來說明core dump的流程。

信號發送

當硬件檢測到alignment fault時，會進入相應的異常處理函數(其他文章已經分析過ARM64的異常處理流程了，可以參考)處理，對于alignment fault，最終會進入do_mem_abort()函數：

/** Dispatch a data abort to the relevant handler.*/ asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,struct pt_regs *regs) {/*從ESR中提取fault信息*/const struct fault_info *inf = fault_info + (esr & 63);struct siginfo info;if (!inf->fn(addr, esr, regs))return;/*我們在messages中看到的打印*/pr_alert("Unhandled fault: %s (0x%08x) at 0x%016lx\n",inf->name, esr, addr);/*填充信號信息*/info.si_signo = inf->sig;info.si_errno = 0;info.si_code = inf->code;info.si_addr = (void __user *)addr;/*通知用戶態程序或者是內核die*/arm64_notify_die("", regs, &info, esr); }

這里的填充的信號是來自ESR，對于alignment fault，默認為SIGBUS信號，然后還是進入了arm64_notify_die（）：

void arm64_notify_die(const char?str, struct pt_regs *regs, struct siginfo *info, int err) { /如果發生異常的上下文處于用戶態，則給相應的用戶態進程發送信號/ if (user_mode(regs)) { current->thread.fault_address = 0; current->thread.fault_code = err; force_sig_info(info->si_signo, info, current); } else { /如果是內核態，則直接die，最終會panic*/ die(str, regs, err); } }

對于用戶態發生的異常，會發送相應的信號，后續的信號發送主要代碼流程為(不詳述)：

force_sig_info -> specific_send_sig_info ->send_signal ->__send_signal

信號處理

信號處理是異步過程，內核向用戶態進程發送信號后，信號并不會得到立即處理，信號的處理時機有幾個，最主要的就是就進程得到調度的時候，當進程得到調度后，就會處理相應的信號，信號處理的主要代碼流程如下：

do_signal ->get_signal ->sig_kernel_coredump ->do_coredump

具體代碼就不列了，有點乏味~，這里主要強調一下，什么信號會最終導致core文件的生成，關鍵就在于SIG_KERNEL_COREDUMP_MASK宏：

#define SIG_KERNEL_COREDUMP_MASK (\rt_sigmask(SIGQUIT) | rt_sigmask(SIGILL) | \rt_sigmask(SIGTRAP) | rt_sigmask(SIGABRT) | \rt_sigmask(SIGFPE) | rt_sigmask(SIGSEGV) | \rt_sigmask(SIGBUS) | rt_sigmask(SIGSYS) | \rt_sigmask(SIGXCPU) | rt_sigmask(SIGXFSZ) | \SIGEMT_MASK

這個宏中列出的信號都會產生core文件，信號不只是內核可以發送，用戶態當然也可以發送，最簡單的就是kill命令，如果向讓某進程產生core文件，可以直接向其發送信號(比如SIGSEGV、SIGBUS)，當然最簡單的可能就是gcore命令了，損傷最小，扯遠了~

相關配置

最后，再補充一下core文件的相關配置，主要就是兩個地方：

/proc/sys/kernel/core_pattern，也可以通過sysctl.conf配置，用于控制core文件的生成規則。

ulimit -c控制core文件的大小，如果設置為0，則不會生成core文件。

不羅嗦其他的了。

原文地址：?http://happyseeker.github.io/kernel/2016/03/04/core-dump-mechanism.html

總結

以上是生活随笔為你收集整理的Core Dump流程分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。