Core Dump调试

环境

本文以笔者操作系统ubuntu14.04 LTS为例介绍core dump功能。
首先查看系统是否使能了core dump功能:

$ ulimit -c
0

返回0表示没有使能,我们需要使能该功能:

ulimit -c 1

示例

#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int main(int argc, char *argv[])
{
    errno = EINVAL;
    printf("Error:%s\n", strerror(errno));
    perror(argv[0]);
    exit(0);
}

编译

使用-g选项重新编译目标执行文件:

gcc test.c -g -o error

运行:

$ ./error
段错误 (核心已转储)
$ ls -a
.  ..  core  error  test.c

产生了一个命名为“core”的文件,这个就是我们需要的core dump文件。

调试

gdb error core

使用gdb加载对应的core dump,需要的格式为:“gdb program_name core_name”

GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
Copyright (C) 2014 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from error...done.
[New LWP 15614]
Core was generated by `./error'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f6b20e61943 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=ap@entry=0x7fff3f3e1a78) at vfprintf.c:1661
1661	vfprintf.c: 没有那个文件或目录.
(gdb) frame
#0  0x00007f6b20e61943 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=ap@entry=0x7fff3f3e1a78) at vfprintf.c:1661
1661	in vfprintf.c
(gdb) bt
#0  0x00007f6b20e61943 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=ap@entry=0x7fff3f3e1a78) at vfprintf.c:1661
#1  0x00007f6b20e6a3d9 in __printf (format=<optimized out>) at printf.c:33
#2  0x0000000000400697 in main (argc=1, argv=0x7fff3f3e1c48) at error.c:8

主要调试命令:

bt: 栈回溯
frame:当前停止位置的frame
frame 1:回到对应标号的frame,标号就是bt命令输出的#数字
info args:查看参数
info locals:查看本地变量
print xxx:打印变量值

除了使用core dump进行调试,还可以直接使用gdb运行程序进行调试:

gdb error

增加如下几个常用的gdb 命令:

b main:设置main为breakpoint
run:开始运行
c:continue的缩写
n:单步运行(不跳入)
s:单步运行(跳入)
finish:跳出

这个示例的错误之处是没有加入头文件:

#include <string.h>

所以printf打印%s会报错。

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
调试coredump时,可以使用gdb来帮助我们定位问题。首先,确保已经安装了gdb工具。接下来,使用gdb打开coredump文件,命令格式为"gdb <可执行文件路径> <coredump文件路径>"。这样就会进入gdb的调试环境。在gdb中,我们可以使用一些命令来获取关于coredump的信息和调试程序。 1. 使用命令"bt"或"backtrace"来查看函数调用栈,这可以告诉我们程序运行到crash的位置之前经过了哪些函数调用。 2. 使用命令"info registers"来查看寄存器的值,这可以帮助我们理解程序在崩溃时的状态。 3. 使用命令"print <变量名>"来查看变量的值,这可以帮助我们了解程序在崩溃时的数据状态。 4. 使用命令"list"来查看源代码,这可以帮助我们找到问题所在的具体代码位置。 5. 使用命令"run"重新运行程序,这可以帮助我们重现coredump并进行调试。 需要注意的是,在调试coredump时,有时候只能从core文件中找出崩溃的直观原因,而更深层次的原因可能需要结合代码和运行上下文来分析。因此,除了使用gdb命令来查看coredump的信息外,还需要对程序的代码进行分析,以便找到问题所在。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [gdb调试coredump(使用篇)](https://blog.csdn.net/jackhh1/article/details/124434307)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT3_1"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值