debugging gdb核心文件分析

fnvucqvd  于 2023-06-30  发布在  其他
关注(0)|答案(1)|浏览(159)

我有核心文件,我试图找出是什么可能导致应用程序崩溃&生成核心文件。当我用gdb和binary运行core文件时,我在gdb提示符上得到了下面的内容:程序终止信号SIGSEGV,分段故障。McSystem::RWCString2RWTime中的#0 0x08d0290f(从=...,到=...),位于McSystem.cpp:1613
当我用上面的地址运行反汇编程序时,我在gdb中得到了下面的结果:

(gdb) disas 0x08d0290f
Dump of assembler code for function McSystem::RWCString2RWTime(STSString const&, STSTime&):
   0x08d02907 <+19>:    push   %ebx
   0x08d02908 <+20>:    push   %eax
   0x08d0290c <+24>:    lea    -0x10(%ebp),%eax
=> 0x08d0290f <+27>:    push   %eax
   0x08d02910 <+28>:    call   0x8da7aa0 <STSTime::STSTime(STSString const&, STSZone const&, STSLocale const&)>
   0x08d02915 <+33>:    add    $0x10,%esp
   0x08d0291e <+42>:    push   %eax
   0x08d0291f <+43>:    call   0x8da8010 <STSTime::isValid() const>

从上方看,箭头标记的线有问题。但我无法理解这里的原因。我想问题与内存冲突无关。当我打印eax时,我得到了下面的值:

(gdb) print $eax
$1 = 1684480973

任何想法都会受到赞赏…

fv2wmkja

fv2wmkja1#

0x08d0290f <+27>: push %eax
当Intel机器上的PUSHCALL指令发生崩溃时,99.999%的情况是由堆栈溢出引起的。
检查ESP寄存器的值,它很有可能位于页边界或略低于页边界。
看看GDB where命令的输出--可能有无限的递归,也可能使用了非常大的堆栈分配。

相关问题