李遲按：

除錯是程式設計師的一項基本能力，經歷過大大小小的實戰，隨著見識的增長，只要用心留意並做總結，相信除錯的能力會越來越好。寫程式不可能沒有bug，只是bug容易不容易被發現，bug的危害大不大。筆者使用coredump除錯很多年了，也有部分的工作筆記，無奈事多人懶，一直沒有好好總結。直到最近幫同學排查bug時，才真正下定決心寫幾篇文章。本文為開篇，主要描述coredump作用及配置的一些注意事項，並給出簡單示例。

一、介紹

程式執行過程中，難免會出現這種或那種錯誤導致其異常崩潰。如果使能了coredump，則操系統在程式出現異常時生成一個檔案，一般名稱為core。該檔案有大量可以幫助我們分析程式狀態的資訊——比如可回溯函式棧幀。與gdb實時執行程式除錯不同，coredump是一種事後分析的手段。特別適合一些錯誤很難重現的程式，例如裝置執行三天後，掛掉了，可能是記憶體洩漏導致記憶體不夠用了，可能哪個模組在一個條件語句中出現了指標非法。使用gdb對coredump檔案可以分析程式崩潰之前執行的程式碼片段，可以幫助我們快速定位錯誤。

二、配置coredump

2.1 使用除錯版本

一般地，在軟體開發階段，都會使用除錯版本。亦即程式使用-g來編譯，另外要注意，不能用strip命令對生成的可執行檔案進行精簡。這一切均是為了可執行檔案保留著除錯資訊，以方便使用gdb進行呼叫。

2.2 設定ulimit

為了在程式崩潰時產生coredump檔案，要設定coredump大小。先進行檢視：

[email protected]:~# ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kb)             unlimited
stack(kb)            8192
coredump(blocks)     0
memory(kb)           unlimited
locked memory(kb)    64
process              545
nofiles              1024
vmemory(kb)          unlimited
locks                unlimited

可以看到，其中coredump一行值為0，此時無法產生coredump檔案。因此要設定其檔案為無限大，命令：

# ulimit -c unlimited

結果如下：

[email protected]:~# ulimit -a

time(seconds)        unlimited
file(blocks)         unlimited
data(kb)             unlimited
stack(kb)            8192
coredump(blocks)     unlimited
memory(kb)           unlimited
locked memory(kb)    64
process              545
nofiles              1024
vmemory(kb)          unlimited
locks                unlimited

另外，要程式執行的同一環境下執行。比如，不能在一個終端設定ulimit，而在另一個終端執行程式，這樣不能生成coredump檔案的。

為了保證coredump檔名稱的唯一性，可以用下面命令設定：
# echo 'core.%e.%s.%t' > /proc/sys/kernel/core_pattern  # 設定生成的coredump檔名稱

2.3 萬一程式因段錯誤等原因崩潰，則會生成core檔案。

2.4 3、有了coredump檔案，就可以結合可執行檔案，使用gdb進行除錯了，命令形式如下：
# gdb hello core

（注：需保證編譯器一致）

三、例項演示

下面使用李遲當年參考uboot原始碼實現的命令列解析程式碼為例。

首先，程式碼編譯時必須帶-g選項。
然後，在命令列中設定core檔案：
[[email protected] creadline]$ ulimit -c unlimited

執行程式：
[[email protected] creadline]$ ./a.out
Hit any key to stop autoboot:  0
You abort.
NotAShell> print
in print ...
Segmentation fault (core dumped)     

(已經產生了coredump檔案)

下面使用gdb除錯：
[[email protected] creadline]$ gdb a.out core.2896

gdb列印資訊如下：
GNU gdb Fedora (6.8-29.fc10)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...


warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
[New process 2896]
#0  0x0084d626 in memcpy () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.9-2.i686 libgcc-4.3.2-7.i386 libstdc++-4.3.2-7.i386
(gdb)

使用bt命令檢視函式呼叫的棧幀(用where命令也可以)：
(gdb) bt
#0  0x0084d626 in memcpy () from /lib/libc.so.6
#1  0x08048660 in ?? ()
#2  0x08049f5d in do_print (argc=1, argv=0xbf8935dc) at my_command.c:31
#3  0x08048cc2 in run_command (cmd=0x804cca0 "print") at command.c:380
#4  0x08049e93 in readline_test ()
#5  0x08049ee6 in main ()
(gdb)
 可以看到最後出現的可疑的程式碼函式為do_print，裡面使用到了memcpy，具體是哪裡，可以用frame NUM檢視棧幀。比如，檢視第2個棧幀：
(gdb) frame 2
#2  0x08049f5d in do_print (argc=1, argv=0xbf8935dc) at my_command.c:31
31          memcpy(p, buffer, 5);
(gdb) 

可以看到，已經輸出了檔名稱、行號、函式等重要資訊。
至此，就可以根據資訊修改程式碼了。

下面給出錯誤函式程式碼片段：
int do_print(int argc, char * const argv[])
{
    printf("in print ...\n");
    char* p = NULL;
    char* buffer = "hello";
    memcpy(p, buffer, 5);     //　　注：拷貝到空指標，錯誤！！！
    return 0;
}

下面在某款嵌入式平臺上進行同時的演示，這裡只給出最後gdb呼叫的過程。

[email protected]:creadline$ arm_v5t_le-gdb readline_arm readline_arm.core.11.1941
GNU gdb 6.3 (MontaVista 6.3-20.0.66.0600975 2006-07-06)
...
Core was generated by `./readline_arm'.
Program terminated with signal 11, Segmentation fault.
...
#0  0x4020f164 in memcpy ()
   from /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/target/lib/libc.so.6
(gdb) bt
#0  0x4020f164 in memcpy ()
   from /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/target/lib/libc.so.6
#1  0x0000b660 in do_print (argc=1, argv=0xbefffcd0) at my_command.c:242
#2  0x00009574 in run_command (cmd=0x16c64 "print") at command.c:380
#3  0x0000af7c in readline_test () at main.c:78
#4  0x0000b20c in main (argc=1, argv=0xbefffe64) at main.c:139
(gdb) frame 1
#1  0x0000b660 in do_print (argc=1, argv=0xbefffcd0) at my_command.c:242
242         memcpy(p, buf, 5);
(gdb)

注：行文不特別區別交叉編譯，對於交叉版本，自行補充交叉字首即可。文中“gdb”表示gdb呼叫器，在x86-linux上其檔案為gdb，而在不同的arm-linux上，檔名稱不同，如可能是arm_v5t_le-gdb，也可能是arm-linux-gdb，還可能是arm-arago-linux-gnueabi-gdb，甚至哪天李遲自己編譯了一個交叉編譯器字首為arm-latelee-，則對應偵錯程式名稱為arm-latelee-gdb。

下一篇文章將演示幾個實際中遇到過的bug的排查例項。

李遲 

2016.5.31 週二 晚