作为工作几年的老程序猿,肯定会遇到coredump,log severity设置的比较高,导致可用的log无法分析问题所在。 更悲剧的是,这个问题不好复现!所以现在你手头唯一的线索就是这个程序的尸体:coredump。你不得不通过它,来寻找问题根源。
通过上几篇文章,我们知道了函数参数是如何传递的,和函数调用时栈是如何变化的;当然了还有AT&T的汇编基础,这些,已经可以使我们具备了一定的调试基础。其实,很多调试还是需要经验+感觉的。当然说这句话可能会被打。但是你不得不承认,随着调试的增多,你的很多推断在解决问题时显得很重要,因此,我们需要不断积累经验,来面对各种case。
导致coredump的原因很多,比如死锁,这些还不要操作系统相关的知识,这些问题的分析不在本文的讨论范围之内。大家敬请期待接下来的文章吧!本文从一个非常典型的coredump入手。
请下载本文用到的coredump: Linux Debugging: coredump 分析入门的材料
首先使用gdb a.out core.25992打开这个core
看一下backtrace是什么: &n

当遇到无法复现的问题时,coredump成为关键线索。本文通过一个典型的coredump案例,介绍如何使用gdb进行分析,包括查看backtrace、检查栈内容,揭示了由于字符串溢出导致的bp恢复失败问题,强调了积累调试经验的重要性。
最低0.47元/天 解锁文章
3860

被折叠的 条评论
为什么被折叠?



