用core dump來偵錯工具段錯誤

標籤：blog   http   使用   os   strong   檔案   io   art   

有的程式可以通過編譯, 但在運行時會出現Segment fault(段錯誤). 這通常都是指標錯誤引起的.但這不像編譯錯誤一樣會提示到檔案->行, 而是沒有任何資訊, 使得我們的調試變得困難起來.

 

1.在一般Linux系統中，預設是不會產生core dump檔案的。通過ulimit -c來查看core dump檔案的大小，一般開始是0。
    可以設定core檔案大小，ulimit -c 1024(kbytes單位)或者ulimit -c unlimited。（注: 使用-c unlimited不限制core檔案大小）
2.產生core檔案: $ sudo  sh -c "ulimit -c unlimited; ./main_arm" # main_arm 是可執行檔名。
3.記得在編譯時間加上 -g 方便調試,注意不要加上最佳化選項 -Os(或者-O0 -O1 ....)
4.用gdb查看core檔案:
    gdb [exec file] [core file]
    如：gdb main_arm core
    在進入gdb後, 用 bt 或 where 命令查看backtrace以檢查發生程式運行到哪裡, 來定位core dump的檔案行.
5.舉例：

[html] view plaincopy 

1. 一個程式cmm_test_tool在啟動並執行時候發生了錯誤，並產生了一個core檔案，如下：  
2.   
3.     -rw-r–r– 1 root cmm_test_tool.c  
4.   
5.     -rw-r–r– 1 root cmm_test_tool.o  
6.   
7.     -rwxr-xr-x 1 root cmm_test_tool  
8.   
9.     -rw——- 1 root core.19344  
10.   
11.     -rw——- 1 root core.19351  
12.   
13.     -rw-r–r– 1 root cmm_test_tool.cfg  
14.   
15.     -rw-r–r– 1 root cmm_test_tool.res  
16.   
17.     -rw-r–r– 1 root cmm_test_tool.log  
18.   
19.     [[email protected]_SIM2 mam2cm]#  
20.   
21. 就可以利用命令gdb進行尋找，參數一是應用程式的名稱，參數二是core檔案，運行  
22.   
23. gdb cmm_test_tool core.19344結果如下：  
24.   
25.     [[email protected]_SIM2 mam2cm]# gdb cmm_test_tool core.19344  
26.   
27.     GNU gdb Red Hat Linux (5.2.1-4)  
28.   
29.     Copyright 2002 Free Software Foundation, Inc.  
30.   
31.     GDB is free software, covered by the GNU General Public License, and you are  
32.   
33.     welcome to change it and/or distribute copies of it under certain conditions.  
34.   
35.     Type “show copying” to see the conditions.  
36.   
37.     There is absolutely no warranty for GDB. Type “show warranty” for details.  
38.   
39.     This GDB was configured as “i386-redhat-linux”…  
40.   
41.     Core was generated by `./cmm_test_tool’.  
42.   
43.     Program terminated with signal 11, Segmentation fault.  
44.   
45.     Reading symbols from /lib/i686/libpthread.so.0…done.  
46.   
47.     Loaded symbols for /lib/i686/libpthread.so.0  
48.   
49.     Reading symbols from /lib/i686/libm.so.6…done.  
50.   
51.     Loaded symbols for /lib/i686/libm.so.6  
52.   
53.     Reading symbols from /usr/lib/libz.so.1…done.  
54.   
55.     Loaded symbols for /usr/lib/libz.so.1  
56.   
57.     Reading symbols from /usr/lib/libstdc++.so.5…done.  
58.   
59.     Loaded symbols for /usr/lib/libstdc++.so.5  
60.   
61.     Reading symbols from /lib/i686/libc.so.6…done.  
62.   
63.     Loaded symbols for /lib/i686/libc.so.6  
64.   
65.     Reading symbols from /lib/libgcc_s.so.1…done.  
66.   
67.     Loaded symbols for /lib/libgcc_s.so.1  
68.   
69.     Reading symbols from /lib/ld-linux.so.2…done.  
70.   
71.     Loaded symbols for /lib/ld-linux.so.2  
72.   
73.     Reading symbols from /lib/libnss_files.so.2…done.  
74.   
75.     Loaded symbols for /lib/libnss_files.so.2  
76.   
77.     #0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6  
78.   
79.     (gdb)  
80.   
81. 進入gdb提示符，輸入where，找到錯誤發生的位置和堆棧，如下：  
82.   
83.     (gdb) where  
84.   
85.     #0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6  
86.   
87.     #1 0×4202d4e7 in strtoul () from /lib/i686/libc.so.6  
88.   
89.     #2 0×0804b4da in GetMaxIDFromDB (get_type=2, max_id=0×806fd20) at cmm_test_tool.c:788  
90.   
91.     #3 0×0804b9d7 in ConstrctVODProgram (vod_program=0×40345bdc) at cmm_test_tool.c:946  
92.   
93.     #4 0×0804a2f4 in TVRequestThread (arg=0×0) at cmm_test_tool.c:372  
94.   
95.     #5 0×40021941 in pthread_start_thread () from /lib/i686/libpthread.so.0  
96.   
97.     (gdb)  

至此，可以看出檔案出錯的位置是函數 GetMaxIDFromDB ，兩個參數分別是2和0×806fd20，這個函數位於原始碼的788行，基於此，我們就可以有針對性的找到問題的根源，並加以解決