g-gdb调试core文件
生活随笔
收集整理的這篇文章主要介紹了
g-gdb调试core文件
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
文章目錄
- core文件
- 判讀是否為core文件
- 打開系統 core dump
- 修改core文件的保存路徑
- gdb調試core文件
最近初步了解了一下core 文件，已經如何將gdb工具與core文件結合調試出現段錯誤的程序
core文件
core是指操作系的程序統核心。當我們的程序在操作系統上運行異常崩潰時，操作系統會將此時系統內存狀態報存下來，放入一個core文件，這個過程叫做core dump,也即是核心轉儲。該過程可以理解為操作系統對內存的快照，保存的內容除了基本內存信息之外還包括寄存器信息（程序指針，棧指針），內存管理信息，程序運行狀態信息等。core文件能夠快速幫助開發者定位出很難發現的程序異常問題。
判讀是否為core文件
一般core文件是以core開頭的，
- 使用命令
readelf讀取存儲該文件的的elf加載表頭信息,其中包含core file的信息
readelf -h /tmp/core-hcli-17503-1556000117ELF Header:Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: CORE (Core file) #文件類型為core文件 Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 64 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 112 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0 - 使用
file命令也可以看到core屬性
file /tmp/core-hcli-17503-1556000117 |grep core/tmp/core-hcli-17503-1556000117: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/b_iscsi/bn_cli/hcli ceph disk add --name ceph -s abcdef -l 10.192.55.180 INTEL'
打開系統 core dump
使用命令ulimit -c [blocks]
-
ulimit -c查看當前系統core文件的大小限制[root@node1 ~]# ulimit -c0這個時候操作系統的
core dump是關閉的，此時如果當前系統程序異常終止也不會生成core文件 -
ulimit -c 1024限制當前系統的core文件大小為1024(blocks)，記住這里的blocks為操作系統塊大小，一般默認為512B,即這里限制core文件大小不超過1024 * 512 B -
ulimit -c unlimited對操作系統生成的core文件大小不做限制 -
使用以上命令打開core dump只會對當前終端有效，如果想要永久生效，需要更改
core dump配置文件如下：
vim /etc/security/limits.conf
增加如下內容#Each line describes a limit for a user in the form: # #<domain> <type> <item> <value> # #下面一行位置為我增加的 #第一列<domain>為用戶限制 #第二列<type>為修改限制的類型是軟件還是硬件,這里因為是內核相關文件，則是soft #第三列<item>為文件屬性 #第四列<value>對屬性具體限制的數值 * soft core unlimited使以上配置文件生效需確保PAM認證配置文件中添加
pam_limits.so庫,同時sshd的登錄服務配置中PAM模塊狀態為啟用USEPAM yes#確保ssh服務啟動是會加載PAM認證模塊 cat /etc/ssh/sshd_config|grep UsePAM UsePAM yes同時在如下配置文件中加入PAM的limits庫
#在centos下該庫是在lib64目錄下，如果該配置中存在加載該庫的語句則不用添加 vim /etc/pam.d/login session required /lib64/security/pam_limits.so以上配置正常的話只需要重新登錄一下終端，
/etc/security/limits.conf中的修改即可生效，我們在ulimit -c中可以看到更改過的結果，且該結果對任何登錄終端都生效。
修改core文件的保存路徑
- 默認生成的
core文件保存在可執行文件路徑下，文件名即為core - 通過修改
/proc/sys/kernel/core_uses_pid文件讓core文件名自動加上進程的pid號變為core.pid
執行echo 1 > /proc/sys/kernel/core_uses_pid - 修改
/proc/sys/kernel/core_pattern修改core文件的文件名和生成路徑
執行命令echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern則將生成的core文件目錄放在/tmp目錄下，同時文件名為core-命令名-pid-時間#如下文件 /tmp/core-ceph_osd_daemon-10089-1556277405 /tmp/core-ceph_osd_daemon-13233-1556352109 /tmp/core-ceph_osd_daemon-14787-1556276292 /tmp/core-ceph_osd_daemon-17754-1556275923
gdb調試core文件
- 使用
gdb 可執行文件絕對路徑 core文件路徑進行調試，如下
gdb /root/ceph_osd_daemon /tmp/core-ceph_osd_daemon-22685-1556352590
進入調試終端，輸入bt即可打印程序異常的函數調用棧，使用list + 異常函數或者list + 代碼行號查看出錯源碼位置，如果還想要繼續進行代碼斷點以及變量跟蹤，則可以進一步調試。使用gdb 可執行文件絕對路徑，進行b line設置斷點進行單步調試[root@node1 ~]# gdb /root/ceph_osd_daemon /tmp/core-ceph_osd_daemon-22685-1556352590 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7 Copyright (C) 2013 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 "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/ceph_osd_daemon...done. [New LWP 22685] Core was generated by `/root/ceph_osd_daemon'. Program terminated with signal 11, Segmentation fault. #0 0x00007f086dadd76b in __strcmp_sse42 () from /lib64/libc.so.6 #我這里系統的libc庫版本較低，所以debuginfo要求需要安裝高版本C庫即可 Missing separate debuginfos, use: debuginfo-install glibc-2.17-222.el7.x86_64 (gdb) bt #查看函數調用棧 #0 0x00007f086dadd76b in __strcmp_sse42 () from /lib64/libc.so.6 #1 0x00000000004041f3 in get_min_value (buff=0x7fffaa8fe700 "14 2", p_infos_a=0x7fffaa8fe300) at ceph_osd_daemon.c:970 #2 0x000000000040464c in get_max_out_num (osds=0x7fffaa8fea90) at ceph_osd_daemon.c:1033 #3 0x0000000000404e97 in ceph_daemon_exec () at ceph_osd_daemon.c:1180 #4 0x000000000040501b in main (argc=1, argv=0x7fffaa902db8) at ceph_osd_daemon.c:1221 (gdb) list 970 #查看出錯的源代碼位置 965 for (i=0; NULL != p_infos_a[i]; i++){ 966 //for (i=0; i < pool_flag - 1 && NULL != p_infos_a[i]; i++){ 967 //for (i=0; i < pool_flag && strlen(p_infos_a[i]); i++){ 968 //printf("<fldb> line:%d\n",__LINE__); 969 printf("<fldb> i:%d\n",i); 970 if (!strcmp(p_infos_a[i]->pool_id,tmp_id)) { 971 strcpy(p_infos_a[i]->min_size,tmp_redu); 972 } 973 } 974 return;
總結
以上是生活随笔為你收集整理的g-gdb调试core文件的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用dd查看磁盘前4个扇区的内容
- 下一篇： ceph nautilus相对于mini