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

[Guillaume MENANT <guillaume dot menant at geensys dot com>]

Thanks a lot for all your answers, i'm currently working with a modified
version of GDb (sparc-elf-gdb delivered by Gaisler). I'm creating a software
which make the link between GDB and an Sparc evaluation board. I'm also
working whith Eclipse (my toolchain is : Eclipse <-> sparc-elf-gdb <-> My
software <-> Evaluation board.

I have this message only one time, and GDB is still working after this
message (the loaded software in the evaluation board is working and also
debugging features). 

In order to modify PC and NPC (next PC in Sparc architecture), GDB sends me
two 'G' commands (the first one with only PC modified and the second one
with the NPC modified. Si in these two messages, all other information is
identical (SP for example). Can it be the reason of this message ?

Thanks.


Michael Snyder-3 wrote:
> 
> 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.
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Previous-frame-identical-to-this-frame-%28corrupt-stack-%29-tp15854428p15867580.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.