Missing separate debuginfos类型崩溃分析

背景说明

今天遇到一个偶现崩溃,因为复现概率非常低,并且出现的时候没有收集coredump信息,因此没有去定位,今天复现了两次,终于被我拿到完整的堆栈信息,堆栈信息如下

分析过程

1.打开堆栈日志,发现0号位置没有具体的函数信息,只能先看1号位置的堆栈信息,通过打印变量,发现都很正常;

2.尝试能否打印出来0号堆栈的信息,尝试安装debuginfo-install,发现安装不了;

3.非常迷茫,没有办法继续定位

4.开始怀疑logger->handler这个属性有问题,我知道logger->handler这是一个函数指针,打印gtc_stderr_logger函数指针,发现跟logger->handler不同。

5.继续打印logger对象,这个对象也比较奇怪,level=1990817720不是一个正常的值,难道这个对象已经被破坏了?

6.gdb调试程序,发现启动的时候logger->handler的值就是gtc_stderr_logger函数指针

7.确认问题,logger对象是野指针。(破坏的原因是我是多线程程序,logger对象在子线程被释放了,主线程继续使用时就出现崩溃)

总结

如果再次遇到堆栈中出现??,可以先从有效信息开始分析,基本上就是有效信息那边出现问题了,后面分析崩溃堆栈,需要仔细,每个变量都要仔细检查一下,

这次分析这么久,是因为自己观察不细致导致的,因此写下该篇博客,来告诫自己分析问题需要仔细认真。

posted on   寒魔影  阅读(35)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 2025年我用 Compose 写了一个 Todo App
· 张高兴的大模型开发实战:(一)使用 Selenium 进行网页爬虫
历史上的今天:
2020-06-18 wrk http压测工具介绍
2020-06-18 etcd 相关介绍
2016-06-18 C语言 百炼成钢21
2016-06-18 C语言错误: CRT detected that the application wrote to memory after end of heap buffer

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
点击右上角即可分享
微信分享提示