linux如何分析coredump,Linux Debugging(五): coredump 分析入门

作为工作几年的老程序猿,肯定会遇到coredump,log severity设置的比较高,导致可用的log无法分析问题所在。 更悲剧的是,这个问题不好复现!所以现在你手头唯一的线索就是这个程序的尸体:coredump。你不得不通过它,来寻找问题根源。

通过上几篇文章,我们知道了函数参数是如何传递的,和函数调用时栈是如何变化的;当然了还有AT&T的汇编基础,这些,已经可以使我们具备了一定的调试基础。其实,很多调试还是需要经验+感觉的。当然说这句话可能会被打。但是你不得不承认,随着调试的增多,你的很多推断在解决问题时显得很重要,因此,我们需要不断积累经验,来面对各种case。

导致coredump的原因很多,比如死锁,这些还不要操作系统相关的知识,这些问题的分析不在本文的讨论范围之内。大家敬请期待接下来的文章吧!本文从一个非常典型的coredump入手。

首先使用gdb a.out core.25992打开这个core

看一下backtrace是什么:

Program received signal SIGSEGV, Segmentation fault.

0x0000000000400703 in __do_global_dtors_aux ()

(gdb) bt

Cannot access memory at address 0x303938373635343b

出错的地方很奇怪,而且整个callstack都被破坏了,因此首先看一下寄存器和bp是否正常:

(gdb) i r

rax 0x7fffffffe040 140737488347200

rbx 0x400820 4196384

rcx 0x3332312c21646c72 3689065110378409074

rdx 0x0 0

rsi 0x40091d 4196637

rdi 0x7fffffffe059 140737488347225

rbp 0x3039383736353433 0x3039383736353433

rsp 0x7fffffffe060 0x7fffffffe060

r8 0x30393837363534 13573712489362740

r9 0x7ffff7dc3680 140737351792256

r10 0xffffffffffffffff -1

r11 0x7ffff7389ae0 140737341070048

r12 0x400660 4195936

r13 0x7fffffffe180 140737488347520

r14 0x0 0

r15 0x0 0

rip 0x400703 0x400703 <__do_global_

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值