崩潰轉(zhuǎn)儲、內(nèi)存轉(zhuǎn)儲、核心轉(zhuǎn)儲、系統(tǒng)轉(zhuǎn)儲……這些全都會產(chǎn)生同樣的產(chǎn)物：一個(gè)包含了當(dāng)應(yīng)用崩潰時(shí)，在那個(gè)特定時(shí)刻應(yīng)用的內(nèi)存狀態(tài)的文件。

這是一篇指導(dǎo)文章，你可以通過克隆示例的應(yīng)用倉庫來跟隨學(xué)習(xí)：

git clone https://github.com/hANSIc99/core_dump_example.git

[[339945]]

信號如何關(guān)聯(lián)到轉(zhuǎn)儲

信號是操作系統(tǒng)和用戶應(yīng)用之間的進(jìn)程間通訊。Linux 使用 POSIX 標(biāo)準(zhǔn)中定義的信號。在你的系統(tǒng)上，你可以在 /usr/include/bits/signum-generic.h 找到標(biāo)準(zhǔn)信號的定義。如果你想知道更多關(guān)于在你的應(yīng)用程序中使用信號的信息，這有一個(gè)信息豐富的 signal 手冊頁。簡單地說，Linux 基于預(yù)期的或意外的信號來觸發(fā)進(jìn)一步的活動。

當(dāng)你退出一個(gè)正在運(yùn)行的應(yīng)用程序時(shí)，應(yīng)用程序通常會收到 SIGTERM 信號。因?yàn)檫@種類型的退出信號是預(yù)期的，所以這個(gè)操作不會創(chuàng)建一個(gè)內(nèi)存轉(zhuǎn)儲。

以下信號將導(dǎo)致創(chuàng)建一個(gè)轉(zhuǎn)儲文件(來源：GNU C庫):

• SIGFPE：錯(cuò)誤的算術(shù)操作
• SIGILL：非法指令
• SIGSEGV：對存儲的無效訪問
• SIGBUS：總線錯(cuò)誤
• SIGABRT：程序檢測到的錯(cuò)誤，并通過調(diào)用 abort() 來報(bào)告
• SIGIOT：這個(gè)信號在 Fedora 上已經(jīng)過時(shí)，過去在 PDP-11 上用 abort() 時(shí)觸發(fā)，現(xiàn)在映射到 SIGABRT

創(chuàng)建轉(zhuǎn)儲文件

導(dǎo)航到 core_dump_example 目錄，運(yùn)行 make，并使用 -c1 開關(guān)執(zhí)行該示例二進(jìn)制：

./coredump -c1 

該應(yīng)用將以狀態(tài) 4 退出，帶有如下錯(cuò)誤：

Dump written“Abgebrochen (Speicherabzug geschrieben) ”(LCTT 譯注：這是德語，應(yīng)該是因?yàn)楸疚淖髡呦到y(tǒng)是德語環(huán)境)大致翻譯為“分段故障(核心轉(zhuǎn)儲)”。

是否創(chuàng)建核心轉(zhuǎn)儲是由運(yùn)行該進(jìn)程的用戶的資源限制決定的。你可以用 ulimit 命令修改資源限制。

檢查當(dāng)前創(chuàng)建核心轉(zhuǎn)儲的設(shè)置：

ulimit -c 

如果它輸出 unlimited，那么它使用的是(建議的)默認(rèn)值。否則，用以下方法糾正限制：

ulimit -c unlimited 

要禁用創(chuàng)建核心轉(zhuǎn)儲，可以設(shè)置其大小為 0：

ulimit -c 0 

這個(gè)數(shù)字指定了核心轉(zhuǎn)儲文件的大小，單位是塊。

什么是核心轉(zhuǎn)儲?

內(nèi)核處理核心轉(zhuǎn)儲的方式定義在：

/proc/sys/kernel/core_pattern 

我運(yùn)行的是 Fedora 31，在我的系統(tǒng)上，該文件包含的內(nèi)容是：

/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h 

這表明核心轉(zhuǎn)儲被轉(zhuǎn)發(fā)到 systemd-coredump 工具。在不同的 Linux 發(fā)行版中，core_pattern 的內(nèi)容會有很大的不同。當(dāng)使用 systemd-coredump 時(shí)，轉(zhuǎn)儲文件被壓縮保存在 /var/lib/systemd/coredump 下。你不需要直接接觸這些文件，你可以使用 coredumpctl。比如說：

coredumpctl list 

會顯示系統(tǒng)中保存的所有可用的轉(zhuǎn)儲文件。

使用 coredumpctl dump，你可以從最后保存的轉(zhuǎn)儲文件中檢索信息：

[stephan@localhost core_dump_example]$ ./coredump  
Application started… 
(…….) 
Message: Process 4598 (coredump) of user 1000 dumped core. 
Stack trace of thread 4598: 
#0 0x00007f4bbaf22625 __GI_raise (libc.so.6) 
#1 0x00007f4bbaf0b8d9 __GI_abort (libc.so.6) 
#2 0x00007f4bbaf664af __libc_message (libc.so.6) 
#3 0x00007f4bbaf6da9c malloc_printerr (libc.so.6) 
#4 0x00007f4bbaf6f49c _int_free (libc.so.6) 
#5 0x000000000040120e n/a (/home/stephan/Dokumente/core_dump_example/coredump) 
#6 0x00000000004013b1 n/a (/home/stephan/Dokumente/core_dump_example/coredump) 
#7 0x00007f4bbaf0d1a3 __libc_start_main (libc.so.6) 
#8 0x000000000040113e n/a (/home/stephan/Dokumente/core_dump_example/coredump) 
Refusing to dump core to tty (use shell redirection or specify — output). 

這表明該進(jìn)程被 SIGABRT 停止。這個(gè)視圖中的堆棧跟蹤不是很詳細(xì)，因?yàn)樗话ê瘮?shù)名。然而，使用 coredumpctl debug，你可以簡單地用調(diào)試器(默認(rèn)為 GDB)打開轉(zhuǎn)儲文件。輸入 bt(回溯backtrace的縮寫)可以得到更詳細(xì)的視圖：

Core was generated by `./coredump -c1'. 
Program terminated with signal SIGABRT, Aborted. 
#0  __GI_raise (sigsig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 
50  return ret; 
(gdb) bt 
#0  __GI_raise (sigsig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 
#1  0x00007fc37a9aa8d9 in __GI_abort () at abort.c:79 
#2  0x00007fc37aa054af in __libc_message (actionaction=action@entry=do_abort, fmtfmt=fmt@entry=0x7fc37ab14f4b "%s\n") at ../sysdeps/posix/libc_fatal.c:181 
#3  0x00007fc37aa0ca9c in malloc_printerr (strstr=str@entry=0x7fc37ab130e0 "free(): invalid pointer") at malloc.c:5339 
#4  0x00007fc37aa0e49c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4173 
#5  0x000000000040120e in freeSomething(void*) () 
#6  0x0000000000401401 in main () 

與后續(xù)幀相比，main() 和 freeSomething() 的內(nèi)存地址相當(dāng)?shù)?。由于共享對象被映射到虛擬地址空間末尾的區(qū)域，可以認(rèn)為 SIGABRT 是由共享庫中的調(diào)用引起的。共享對象的內(nèi)存地址在多次調(diào)用之間并不是恒定不變的，所以當(dāng)你看到多次調(diào)用之間的地址不同時(shí)，完全可以認(rèn)為是共享對象。

堆棧跟蹤顯示，后續(xù)的調(diào)用源于 malloc.c，這說明內(nèi)存的(取消)分配可能出了問題。

在源代碼中，(即使沒有任何 C++ 知識)你也可以看到，它試圖釋放一個(gè)指針，而這個(gè)指針并沒有被內(nèi)存管理函數(shù)返回。這導(dǎo)致了未定義的行為，并導(dǎo)致了 SIGABRT。

void freeSomething(void *ptr){ 
    free(ptr); 
} 
int nTmp = 5; 
int *ptrNull = &nTmp; 
freeSomething(ptrNull); 

systemd 的這個(gè) coredump 工具可以在 /etc/systemd/coredump.conf 中配置。可以在 /etc/systemd/systemd-tmpfiles-clean.timer 中配置輪換清理轉(zhuǎn)儲文件。

你可以在其手冊頁中找到更多關(guān)于 coredumpctl 的信息。

用調(diào)試符號編譯

打開 Makefile 并注釋掉第 9 行的最后一部分?，F(xiàn)在應(yīng)該是這樣的：

CFLAGS =-Wall -Werror -std=c++11 -g 

-g 開關(guān)使編譯器能夠創(chuàng)建調(diào)試信息。啟動應(yīng)用程序，這次使用 -c2 開關(guān)。

./coredump -c2 

你會得到一個(gè)浮點(diǎn)異常。在 GDB 中打開該轉(zhuǎn)儲文件：

coredumpctl debug 

這一次，你會直接被指向源代碼中導(dǎo)致錯(cuò)誤的那一行：

Reading symbols from /home/stephan/Dokumente/core_dump_example/coredump… 
[New LWP 6218] 
Core was generated by `./coredump -c2'. 
Program terminated with signal SIGFPE, Arithmetic exception. 
#0 0x0000000000401233 in zeroDivide () at main.cpp:29 
29 nRes = 5 / nDivider; 
(gdb) 

鍵入 list 以獲得更好的源代碼概覽：

(gdb) list 
24      int zeroDivide(){ 
25          int nDivider = 5; 
26          int nRes = 0; 
27          while(nDivider > 0){ 
28              nDivider--; 
29              nRes = 5 / nDivider; 
30          } 
31          return nRes; 
32      } 

使用命令 info locals 從應(yīng)用程序失敗的時(shí)間點(diǎn)檢索局部變量的值：

(gdb) info locals 
nDivider = 0 
nRes = 5 

結(jié)合源碼，可以看出，你遇到的是零除錯(cuò)誤：

nRes = 5 / 0 

結(jié)論

了解如何處理轉(zhuǎn)儲文件將幫助你找到并修復(fù)應(yīng)用程序中難以重現(xiàn)的隨機(jī)錯(cuò)誤。而如果不是你的應(yīng)用程序，將核心轉(zhuǎn)儲轉(zhuǎn)發(fā)給開發(fā)人員將幫助她或他找到并修復(fù)問題。