Linux上coredump调试：call stack栈顶函数地址为0 分析实战

最新推荐文章于 2024-08-07 07:38:36 发布

罗米Romi

最新推荐文章于 2024-08-07 07:38:36 发布

阅读量1.6k

点赞数

CC 4.0 BY-SA版权

分类专栏：代码调试 c 文章标签： gdb Linux coredump 调

本文链接：https://blog.youkuaiyun.com/iamguantengfei/article/details/9699845

这篇博客详细介绍了在Linux环境下，遇到coredump时调用栈顶部函数地址为0的问题。作者通过gdb调试，发现是由于对象被破坏，虚函数表被覆盖导致。通过分析汇编代码和内存内容，确认了对象在多线程环境中因互斥锁使用不当而过早释放。博客强调了解析call stack和熟悉X86_64调用约定的重要性，以及多线程中正确使用锁的必要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这几天测试中，又收到了coredump的报告，调用栈如下：

(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x0000000000432bb4 in ChargingNode::canProcessed (this=0x7f87b40118e0, maxTimestamp=9000000000) at src/sl/ChargingFile.C:406
#2 0x0000000000445de4 in BucketFileAdapter::checkin (this=0x2192b98, startTime=<value optimized out>) at src/sl/BucketFileAdapter.C:118
#3 0x0000000000446114 in BucketFileAdapter::start (this=0x2192b98) at src/sl/BucketFileAdapter.C:87
#4 0x000000000043560e in file_reader_run (arg=0x2192b98) at src/sl/ChargingFileAdapter.C:234
#5 0x0000003657607851 in start_thread () from /lib64/libpthread.so.0
#6 0x0000003656ee890d in clone () from /lib64/libc.so.6

栈顶函数地址为0x0。

这是一个很有意思的现象，以前我没有遇到这种case。

结合代码看看：出错行的C++代码：

if(chargingFile && (chargingFile ->canDecoded() == false))

用gdb看chargingFile的值，结果显示被优化了（使用了-O2）：

(gdb) p chargingFile
$3 = <value optimized out>

那我们分析下frame 1 对应的C++代码，chargingFile即使为NULL也不可能导致core，所以只可能是chargingFIle不空，但调用canDecode（）函数时出问题了。

对应反汇编代码：

(gdb) disas
Dump of assembler code for function ChargingNode::canProcessed(long):
0x0000000000432b20 <+0>: mov %rbx,-0x18(%rsp)
0x0000000000432b25 <+5>: lea 0x78(%rdi),%rbx
0x0000000000432b29 <+9>: mov %rbp,-0x10(%rsp)
0x0000000000432b2e <+14>: mov &nb