導航:首頁 > 版本升級 > gdb查看core文件

gdb查看core文件

發布時間:2024-12-20 07:33:36

Ⅰ 如何察看core文件的內容

一般步驟1.filecore文件,可以顯示出core文件是哪個進程產生的2.使用gdb或者dbx載入core文件,gdb進程名core文件3.where,顯示堆棧信息,顯示出coremp的地方例如有個程序叫ABC,產生了一個叫core的core文件,那麼輸入filecore,會顯示這個core文件是由ABC產生的,然後輸入gdbABCcore裝截core文件,然後輸入where顯示堆棧信息

Ⅱ core文件如何查看和調試

在Unix系統下,應用程序崩潰,一般會產生core文件,如何根據core文件查找問題的所在,並做相應的分析和調試,是非常重要的,本文對此做簡單介紹。

例如,一個程序cmm_test_tool在運行的時候發生了錯誤,並生成了一個core文件,如下:

-rw-r–r– 1 root cmm_test_tool.c
-rw-r–r– 1 root
cmm_test_tool.o
-rwxr-xr-x 1 root cmm_test_tool
-rw--- 1 root
core.19344
-rw--- 1 root core.19351
-rw-r–r– 1 root
cmm_test_tool.cfg
-rw-r–r– 1 root cmm_test_tool.res
-rw-r–r– 1 root
cmm_test_tool.log
[root@AUTOTEST_SIM2 mam2cm]#

就可以利用命令gdb進行查找,參數一是應用程序的名稱,參數二是core文件,運行
gdb
cmm_test_tool core.19344結果如下:

[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344
GNU gdb Red Hat
linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free
software, covered by the GNU General Public License, and you are
welcome to
change it and/or distribute copies of it under certain conditions.
Type 「show
ing」 to see the conditions.
There is absolutely no warranty for GDB. Type
「show warranty」 for details.
This GDB was configured as
「i386-redhat-linux」…
Core was generated by `./cmm_test_tool』.
Program
terminated with signal 11, Segmentation fault.
Reading symbols from
/lib/i686/libpthread.so.0…done.
Loaded symbols for
/lib/i686/libpthread.so.0
Reading symbols from
/lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading
symbols from /usr/lib/libz.so.1…done.
Loaded symbols for
/usr/lib/libz.so.1
Reading symbols from
/usr/lib/libstdc++.so.5…done.
Loaded symbols for
/usr/lib/libstdc++.so.5
Reading symbols from
/lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading
symbols from /lib/libgcc_s.so.1…done.
Loaded symbols for
/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2…done.
Loaded
symbols for /lib/ld-linux.so.2
Reading symbols from
/lib/libnss_files.so.2…done.
Loaded symbols for /lib/libnss_files.so.2
#0
0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
(gdb)

進入gdb提示符,輸入where,找到錯誤發生的位置和堆棧,如下:

(gdb) where
#0 0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
#1 0×4202d4e7 in strtoul () from
/lib/i686/libc.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_tool.c:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0×0804a2f4 in
TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0×40021941 in
pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)

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

Ⅲ gdb怎麼查看程序是在哪行代碼那裡執行了exit退出

gdb 查看 core 文件

基本上
core 文件就是一個包含了程序崩潰時這個進程的所有信息的文件。在那 「遙遠的黃金年代」,程序員不得不把 core 文件以十六進制的方式顯示
出來,然後滿頭大汗的閱讀機器碼的手冊,但是現在事情就簡單得多了。順便說一下, 在 FreeBSD 和其他的 4.4BSD 系統下,core 文件都叫作
progname.core 而不是簡單叫 core,這樣可以很清楚的表示出這個 core
文件是屬於哪個 程序。

1. 要檢查一個 core 文件,首先用 gdb 可執行文件名
來調試產生core文件的可執行程序:

2. 命令 core會分析 可執行程序名.core
文件
註:如果當前不是 core 文件所在目錄,首先要執行 dir
/可執行程序名.core的路徑/。
(gdb)core 可執行程序名.core

舉例:
$gdb a.out
GDB is free software and you are
welcome to distribute copies of it under certain conditions; type "show ing"
to see the conditions. There is absolutely no warranty for GDB; type "show
warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free
Software Foundation, Inc.

(gdb)core
a.out.core
Core was generated by `a.out'.
Program terminated with
signal 11, Segmentation fault.
Cannot access memory at address
0x7020796d.
#0 0x164a in bazz (anint=0x5) at temp.c:17
(gdb)

這種情況下,運行的程序叫 a.out,因此 core 文件 就叫
a.out.core。我們知道程序崩潰的原因就是函數 bazz 試圖訪問一塊不屬於它的內存。

有時候,能知道一個函數是怎麼被調用的是非常有用處的。因為在一個復雜的程序裡面問題可能會發生在函數調用棧上面很遠的地方。

3.
命令 bt 會讓 gdb
輸出函數調用棧的回溯追蹤
(gdb)bt
#0 0x164a in bazz (anint=0x5) at temp.c:17
#1 0xefbfd888 in end ()
#2 0x162c in main () at temp.c:11
(gdb)

函數 end() 在一個程序崩潰的時候將被調用;
在本例
中,函數 bazz()
是從 main()中被調用的。

Ⅳ 如何查看core文件是哪個進程的

一般步驟
1. file core文件,可以顯示出core文件是哪個進程產生的
2.使用gdb或者dbx載入專core文件, gdb 進程名 core文件
3.where,顯示堆棧信息,顯示出屬coremp的地方
例如有個程序叫 ABC,產生了一個叫core的core文件,
那麼輸入 file core, 會顯示 這個core文件是由ABC產生的,
然後輸入 gdb ABC core裝截core文件,
然後 輸入 where 顯示堆棧信息

Ⅳ 怎樣用GDB調試core文件

一般這種情況都是因為數組越界訪問,空指針或是野指針讀寫造成的。程序小的話還比較好辦,對著源代碼仔細檢查就能解決。但是對於代碼量較大的程序,里邊包含N多函數調用,N多數組指針訪問,這時想定位問題就不是很容易了(此時牛人依然可以通過在適當位置打printf加二分查找的方式迅速定位:P)。懶人的話還是直接GDB搞起吧。 神馬是Core Dump文件偶爾就能聽見某程序員同學抱怨「擦,又出Core了!」。簡單來說,core mp說的是操作系統執行的一個動作,當某個進程因為一些原因意外終止(crash)的時候,操作系統會將這個進程當時的內存信息轉儲(mp)到磁碟上1。產生的文件就是core文件了,一般會以core.xxx形式命名。 如何產生Core Dump 發生doremp一般都是在進程收到某個信號的時候,Linux上現在大概有60多個信號,可以使用 kill -l 命令全部列出來。sagi@sagi-laptop:~$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX針對特定的信號,應用程序可以寫對應的信號處理函數。如果不指定,則採取默認的處理方式, 默認處理是coremp的信號如下:3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS 5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT 我們看到SIGSEGV在其中,一般數組越界或是訪問空指針都會產生這個信號。另外雖然默認是這樣的,但是你也可以寫自己的信號處理函數改變默認行為,更多信號相關可以看參考鏈接33。 上述內容只是產生coremp的必要條件,而非充分條件。要產生core文件還依賴於程序運行的shell,可以通過ulimit -a命令查看,輸出內容大致如下:sagi@sagi-laptop:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 看到第一行了吧,core file size,這個值用來限制產生的core文件大小,超過這個值就不會保存了。我這里輸出是0,也就是不會保存core文件,即使產生了,也保存不下來==! 要改變這個設置,可以使用ulimit -c unlimited。 OK, 現在萬事具備,只缺一個能產生Core的程序了,介個對C程序員來說太容易了。#include ; #include ; int crash() { char *xxx = "crash!!"; xxx[1] = 'D'; // 寫只讀存儲區! return 2; } int foo() { return crash(); } int main() { return foo(); } 上手調試 上邊的程序編譯的時候有一點需要注意,需要帶上參數-g, 這樣生成的可執行程序中會帶上足夠的調試信息。編譯運行之後你就應該能看見期待已久的「Segment Fault(core mped)」或是「段錯誤 (核心已轉儲)」之類的字眼了。看看當前目錄下是不是有個core或是core.xxx的文件。祭出linux下經典的調試器GDB,首先帶著core文件載入程序:gdb exefile core,這里需要注意的這個core文件必須是exefile產生的,否則符號表會對不上。載入之後大概是這個樣子的:sagi@sagi-laptop:~$ gdb coremp core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in crash () at coremp.c:8 8 xxx[1] = 'D'; (gdb)我們看到已經能直接定位到出core的地方了,在第8行寫了一個只讀的內存區域導致觸發Segment Fault信號。在載入core的時候有個小技巧,如果你事先不知道這個core文件是由哪個程序產生的,你可以先隨便找個代替一下,比如/usr/bin/w就是不錯的選擇。比如我們採用這種方法載入上邊產生的core,gdb會有類似的輸出:sagi@sagi-laptop:~$ gdb /usr/bin/w core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in ? () (gdb)可以看到GDB已經提示你了,這個core是由哪個程序產生的。 GDB 常用操作 上邊的程序比較簡單,不需要另外的操作就能直接找到問題所在。現實卻不是這樣的,常常需要進行單步跟蹤,設置斷點之類的操作才能順利定位問題。下邊列出了GDB一些常用的操作。 啟動程序:run
設置斷點:b 行號|函數名
刪除斷點:delete 斷點編號
禁用斷點:disable 斷點編號
啟用斷點:enable 斷點編號
單步跟蹤:next 也可以簡寫 n
單步跟蹤:step 也可以簡寫 s
列印變數:print 變數名字
設置變數:set var=value
查看變數類型:ptype var
順序執行到結束:cont
順序執行到某一行: util lineno列印堆棧信息:bt

閱讀全文

與gdb查看core文件相關的資料

熱點內容
工作室網站如何布局 瀏覽:608
資料庫開發工程師需要學什麼 瀏覽:553
高速網是什麼網站 瀏覽:392
如何通過數據查看屏幕廠家 瀏覽:858
深圳市編程貓怎麼樣 瀏覽:130
硬碟損壞pe中如何數據恢復 瀏覽:411
鎮魔曲安卓蘋果互通嗎 瀏覽:825
市場規模數據怎麼看 瀏覽:228
win10怎末設置動態桌面 瀏覽:457
網路沒有聲音怎麼辦 瀏覽:919
如何增加網路回訪率 瀏覽:161
哪個網站有賣手賬素材包 瀏覽:319
手機網路電視直播軟體哪個好 瀏覽:614
魅藍手機怎麼用舊版本 瀏覽:47
貨車超載違法代碼16375 瀏覽:887
學習網路編程用什麼語言 瀏覽:995
手機文件夾合並 瀏覽:806
hao123轉js 瀏覽:864
買保健品去哪個網站 瀏覽:947
word中未保存文件在哪裡找 瀏覽:228

友情鏈接