Re: Previous frame identical to this frame (corrupt stack?)

[Michael Snyder <msnyder at specifix dot com>]

On Wed, 2008-03-05 at 08:36 -0800, Guillaume MENANT wrote:
> What does it means ? What have I to look at in order to check if I have an
> mistake in my program ?

Well, the only thing we know for sure is that GDB tried
to fetch the next stack frame, and came up with an answer
that was identical with the one before.

In this context, "identical" should mean "same PC, and
same SP/FP (stack/frame pointer)".

So, since this should not happen (and really means that
further stack trace is impossible), gdb gives up.

The *cause* is something else again.  Difficult to
know, but as the message implies, one likely cause
is stack corruption.  You could look at the stack, 
starting at the last good-looking stack frame that
gdb was able to find, and try to see if it looks "sane".

In practice, the most frequent case where I have seen
this message is when we really have reached the end
of the stack.  Usually the bottom frame is some sort
of thread creation function, possibly in the kernel
or in some thread library.  In this context, what
has usually happened is that the author of the thread
creation function has not bothered to set up some 
sort of initial "zero" stack pointer so that the 
debugger can detect the end of the stack.