Expanding on what Mara said:
Quote:
Originally Posted by m4rtin
Code:
#0 0x88d86437 in ?? ()
#1 0x88c9b204 in ?? ()
#2 0x000007ea in ?? ()
|
Line #2 in that backtrace is garbage. Once one line is garbage, it is unlikely that any further lines are OK.
I wouldn't say with confidence that lines #0 and #1 are OK, but they are the most that might be OK in that backtrace.
So you can be pretty sure that something trashed some copy of the frame pointer, so gdb can't give a correct backtrace.
If you knew a bit about gdb and asm code, you could look at the disassembly around addresses 0x88d86437 and 0x88c9b204 to see if that code is plausible enough to be valid backtrace levels.
If they're not plausible, you're totally lost. But even if they are, you're pretty much lost. If they are valid stack frames then the object that overran is two frames up the stack from where the crash happened, which makes it likely the bug was relatively long before the crash in execution history. Those are hard to find even when you have symbols and source code.
Quote:
What might be the cause of this crash? Or is it possible to further debug this problem(it's not open source program)?
|
If you knew assembler well, you could probably easily find the data structure on the stack that had the overrun that caused the crash (I'm assuming but can't be certain that a stacked data structure overrun caused this crash). Then you could look at the data structure. If it happens to contain readable text, you might guess what chunk of data the program tried to process that exceeds some unenforced limit. That's all the most optimistic answer to your question.
The more realistic answer is that it is impossible to diagnose. If you were someone for whom such diagnosis is really hard (rather than impossible) you wouldn't have needed to ask.