I am having a core dump in which the stack is corrupted. I tried to disassemble it and found the following. I want to analyze it:
(gdb) bt
#0 0x55a63c98 in ?? ()
#1 0x00000000 in ?? ()
(gdb) disassemble 0x55a63c90 0x55a63ca8
Dump of assembler code from 0x55a63c90 to 0x55a63ca8:
0x55a63c90: add %cl,%dh
0x55a63c92: cmpsb %es:(%edi),%ds:(%esi)
0x55a63c93: push %ebp
0x55a63c94: add %al,(%eax)
0x55a63c96: add %al,(%eax)
**0x55a63c98: pusha**
0x55a63c99: lret $0x9
0x55a63c9c: subb $0x56,0xd005598(%ebp)
0x55a63ca3: push %ebp
0x55a63ca4: jo 0x55a63cc5
0x55a63ca6: sahf
0x55a63ca7: push %ebp
End of assembler dump.
(gdb) q
Can this pusha instruction lead to a core dump?
No*, all pusha does is push all the general-purpose registers to the stack, including the stack pointer! What is causing the core dump is the instruction after the pusha, lret, which is a long return with stack pop. The return address is the most recent value pushed to the stack, which in this case will be whatever was in esi:edi (since they are the last values to be pushed by the pusha instruction), and that's likely to point to somewhere random.
* Unless you run out of stack space.