Previous frame identical to this frame (corrupt stack?)

Previous frame identical to this frame (corrupt stack?)

[Guillaume MENANT]

What does it means ? What have I to look at in order to check if I have an
mistake in my program ?

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

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

[Joel Brobecker]

> What does it means ? What have I to look at in order to check if I have an
> mistake in my program ?

You really didn't provide much information (either GDB version,
platform, etc). But it could be either:
  - a corrupt call-stack, or maybe corrupt debugging info (frame info)
  - a bug in GDB

You can try using GDB from CVS head to see if you have better results.
Otherwise, you will need to inspect the frame where the backtrace stops,
and verify that it is not screwed. You might also have to check the
frame info data if your executable has them.

-- 
Joel

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

[Aleksandar Ristovski]

Joel Brobecker wrote:
>> What does it means ? What have I to look at in order to check if I have an
>> mistake in my program ?
> 
> You really didn't provide much information (either GDB version,
> platform, etc). But it could be either:
>   - a corrupt call-stack, or maybe corrupt debugging info (frame info)
>   - a bug in GDB

You might also be experiencing a library mismatch.

> 
> You can try using GDB from CVS head to see if you have better results.
> Otherwise, you will need to inspect the frame where the backtrace stops,
> and verify that it is not screwed. You might also have to check the
> frame info data if your executable has them.
> 

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

[Andrew STUBBS]

Aleksandar Ristovski wrote:
> Joel Brobecker wrote:
>>> What does it means ? What have I to look at in order to check if I 
>>> have an
>>> mistake in my program ?
>>
>> You really didn't provide much information (either GDB version,
>> platform, etc). But it could be either:
>>   - a corrupt call-stack, or maybe corrupt debugging info (frame info)
>>   - a bug in GDB
> 
> You might also be experiencing a library mismatch.

Or it might just have run out of stack frames, but has no way to tell. 
I'm not sure what the current behaviour is, but at least one past 
version of GDB gives this message in this case.

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

[Michael Snyder]

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.

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

[Guillaume MENANT]

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.

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

[Mark Kettenis]

> From: "Michael Snyder" <msnyder@specifix.com>
> Date: Wed, 05 Mar 2008 12:42:05 -0800
> 
> 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 ?
> 
> 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.

Or that the GDB target does not bother to check for that condition.  Some
thread libraries actually do bother to set up the stack in a way that makes
it possible to detect the end of the stack, but GDB simply doesn't have the
code to detect this.

And on open source operating systems we could make sure that the
thread creation function has a unique name and check for that much like we
terminate the stack trace as we do for main().

But apparently people are not annoyed enough with seeing this message
to write the actual code ;).

Mark