gdb核心文件分析

huangapple go评论51阅读模式
英文:

gdb core file analysis

问题

以下是您要翻译的内容:

我有核心文件,正在尝试找出是什么导致应用程序崩溃并生成核心文件。当我使用gdb和二进制文件运行核心文件时,在gdb提示符上得到以下信息:
程序因信号SIGSEGV,分段错误而终止。
#0 0x08d0290f位于McSystem :: RWCString2RWTime(from = ...,to = ...)的McSystem.cpp中的第1613行

当我使用上面的地址运行反汇编时,在gdb中得到以下信息:

(gdb) disas 0x08d0290f
函数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

任何想法将不胜感激...

英文:

I have core file and I am trying to find out what might have caused the app to crash & generate core file. When I run core file with gdb and binary, I get got below on gdb prompt:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x08d0290f in McSystem::RWCString2RWTime (from=..., to=...) at McSystem.cpp:1613

when I run the disassemble with above address, I got below in gdb:

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

From above the line marked by arrow has problem. But I am not able to understand the cause here.
Issue is not related to memory violation I guess. When I print eax I got below value:

(gdb) print $eax
$1 = 1684480973

Any thoughts would appreciated...

答案1

得分: 0

当在英特尔计算机上发生PUSHCALL指令的崩溃时,99.999%的情况下是由堆栈溢出引起的。

检查ESP寄存器的值,很可能在页面边界上方或接近边界。

查看GDB where命令的输出--您可能有无限递归,或者您可能正在使用非常大的堆栈分配。

英文:

> 0x08d0290f &lt;+27&gt;: push %eax

When a crash happens on PUSH or CALL instruction on Intel machines, 99.999% of the time it is caused by stack overflow.

Examine the value of the ESP register, and chances are it's at or just below page boundary.

Look at the output from GDB where command -- you may have infinite recursion, or you could be using very large stack allocations.

huangapple
  • 本文由 发表于 2023年6月26日 22:38:39
  • 转载请务必保留本文链接:https://go.coder-hub.com/76557711.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定