Search code examples
debugginggdbcoredump

gdb core file analysis


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&, 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>

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...


Solution

  • 0x08d0290f <+27>: 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.