Linux下關于coredump的定位方法說明

更新時間：2023年09月04日 08:52:53 作者：凌肖戰(zhàn)

這篇文章主要介紹了Linux下關于coredump的定位方法說明,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教

一. Linux 下 cordump 機制

Linux 系統(tǒng)下存在一種 coredump 機制。

當程序運行過程中異常終止或崩潰，Linux 操作系統(tǒng)會將程序當時的堆棧等內存狀態(tài)信息記錄下來，會在指定文件下生成一個 coredump 相關的 Log 文件。

軟件開發(fā)人員可以通過對 coredump文件進行分析，即可定位到導致程序運行崩潰的 bug。

當程序訪問的內存超過了系統(tǒng)給定的內存空間，就會產生 Segmentation fault（core dumped），所以：

一般產生段錯誤的原因有如下：

1. 訪問了不存在的內存地址。
2. 訪問了系統(tǒng)保護的內存地址。
3. 數(shù)組或堆空間訪問越界，等等一系列內存非法訪問操作。

二. coredump 文件定位方法

根據(jù)上一篇配置 coredump 機制的方法，成功配置好之后。

就可以運行代碼，當程序運行中崩潰時即可產生相應的 coredump 文件。

操作如下：

1. 首先，開啟 coredump 功能。設置成功后，可以通過 ulimit -c 命令驗證。
2. 其次，關閉 ubuntu 系統(tǒng)下 apport.service 服務程序。
3. 其次，編譯代碼。編譯時必須加 -g 編譯選項（帶調試信息的編譯選項）。
4. 最后，運行程序。當程序運行時出現(xiàn) 核心轉儲等提示錯誤時，即可生成 coredump 文件。

這里為了方便起見，不更改 coredump 文件的生成路徑，即生成的 coredump 文件會與可執(zhí)行程序在同一目錄下，文件默認叫 core 的文件。

下面以一段測試代碼說明一下，Linux 環(huán)境下使用 gdb 調試器對 coredump 文件進行分析調試。

代碼如下：

#include <stdio.h>
#include <string.h>
#include <unistd.h>
int fun()
{
    printf("---fun()\n");
    char buffer[3] = {0}; 
    memcpy(buffer, "Hello", 6);  
    printf("---buffer: %s\n", buffer);  
    return 0;
}
int main()
{
    printf("---main()---\n");   
    int pid = 0;
    pid = getpid();
    printf("pid %d\n", pid);
    fun(); 
    printf("---End main\n");
    return 0;
}

1. 編譯運行

操作如下：

編譯代碼。輸入 gcc -g main.c -o main.out 命令

運行程序。輸入 ./main.out 命令。

如下所示：

wangtian@wangtian-virtual-machine:~/Code_Learns/C_Learns/debug/debug2$ ./main.out 
---main()---
pid 3814
---fun()
---buffer: Hello
*** stack smashing detected ***: terminated
已放棄 (核心已轉儲)

當程序出現(xiàn)段錯誤時崩潰時，可查看程序當前目錄下是否生成 coredump 相關文件。

如下所示：

wangtian@wangtian-virtual-machine:~/Code_Learns/C_Learns/debug/debug2$ ls -l
總用量 180
-rw------- 1 wangtian wangtian 393216 12月 13 16:55 core
drwxrwxr-x 2 wangtian wangtian   4096 11月 25 22:24 debug
-rw-rw-r-- 1 wangtian wangtian     90 10月 28 13:32 debug.c
-rw-rw-r-- 1 wangtian wangtian     81 10月 20 18:12 debug.h
-rw-rw-r-- 1 wangtian wangtian   5688 12月 13 16:55 debug.o
-rw-rw-r-- 1 wangtian wangtian    356 12月 13 16:55 main.c
-rw-rw-r-- 1 wangtian wangtian   7144 12月 13 16:55 main.o
-rwxrwxr-x 1 wangtian wangtian  21144 12月 13 16:55 main.out

2. gdb 調試 coredump 文件

查看 coredump 文件。

輸入 objdump -t core 命令：

wangtian@wangtian-virtual-machine:~/Code_Learns/C_Learns/debug/debug2$  objdump -t core
core：     文件格式 elf64-x86-64
SYMBOL TABLE:
無符號

可以看到，coredump 文件是不帶符號表的。

所以調試時，需要同時加上可執(zhí)行程序文件。

輸入命令 gdb main.out core 進行調試，如下所示：

wangtian@wangtian-virtual-machine:~/Code_Learns/C_Learns/debug/debug2$ gdb main.out core
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.out...
[New LWP 4272]
Core was generated by `./main.out'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: 沒有那個文件或目錄.

可以看到，程序收到 signal SIGABRT 后崩潰了。

輸入 bt (backtrace 縮寫) 命令，可以查看下程序崩潰時的堆棧信息，

如下所示：

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ff8d6f5c859 in __GI_abort () at abort.c:79
#2  0x00007ff8d6fc729e in __libc_message (action=action@entry=do_abort, 
    fmt=fmt@entry=0x7ff8d70f108f "*** %s ***: terminated\n")
    at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ff8d7069aea in __GI___fortify_fail (
    msg=msg@entry=0x7ff8d70f1077 "stack smashing detected") at fortify_fail.c:26
#4  0x00007ff8d7069ab6 in __stack_chk_fail () at stack_chk_fail.c:24
#5  0x000056183642c243 in fun () at main.c:12
#6  0x000056183642c28c in main () at main.c:20

以上的堆棧信息，顯示 __stack_chk_fail () 錯誤?？梢钥吹秸{用 fun() 函數(shù)過程中發(fā)生了棧問題。

__stack_chk_fail () 打印信息說明發(fā)生了緩沖區(qū)溢出，即數(shù)組越界問題。

從這段棧信息中并不能直觀的定位到出現(xiàn)問題的地方，因為出現(xiàn)問題的地方是之前的數(shù)組越界，但是這里的棧信息已經執(zhí)行到主函數(shù) main中, 特別是在大項目中更是無法準確的定位出錯的地方。

越界寫壞內存，什么時候會 crash 取決于我們寫壞的內存什么時候被用到，有時候會離犯罪現(xiàn)場特別遠。所以，導致定位這樣情況的崩潰問題比較麻煩。

在發(fā)生__stack_chk_fail () 錯誤的附近函數(shù) fun() 中第11 行打斷點，如下所示：

(gdb) b main.c:11
Breakpoint 1 at 0x56183642c22a: file main.c, line 11.
(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x000056183642c22a in fun at main.c:11
(gdb) r
Starting program: /home/wangtian/Code_Learns/C_Learns/debug/debug2/main.out 
---main()---
pid 3868
---fun()
---buffer: Hello
Breakpoint 1, fun () at main.c:11
11	    return 0;
(gdb) n
12	}
(gdb) 
*** stack smashing detected ***: terminated
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: 沒有那個文件或目錄.
(gdb)

初步可以定位到，是在函數(shù) fun() 內部發(fā)生了數(shù)組越界問題。目前還不能定位到具體某一行。

canary 棧溢出保護機制的具體原理：

gcc 編譯器默認開啟了 canary 棧保護機制。
canray 棧保護機制是專門針對棧溢出攻擊涉及的一中保護機制。
由于棧溢出攻擊的主要目標是通過溢出覆蓋函數(shù)棧高位的返回地址，因此，其思路是在函數(shù)開始執(zhí)行前，即返回地址前寫入一個字長的隨機數(shù)據(jù)（canary），在函數(shù)返回前校驗該值是否被改變，如果改變則認為是棧溢出，程序直接終止，以此來防止信息泄露。