Help: corrupt Stack

Help: corrupt Stack

[Bizhan Gholikhamseh (bgholikh)]

Hi All,
We are using gdb version 6.3. When we ran gdb on the core dump
generated, it complains with following messages:
"Previous frame identical to this frame (corrupt stack?)"
Is this a known bug, is there a work around or patch
available?
 
Many thanks in advance,
Bizhan

Re: Help: corrupt Stack

[Joel Brobecker]

> We are using gdb version 6.3. When we ran gdb on the core dump
> generated, it complains with following messages:
> "Previous frame identical to this frame (corrupt stack?)"
> Is this a known bug, is there a work around or patch
> available?

I am afraid you are not providing enough information for anyone
to help you here. 6.3 is pretty old at this point, so you should
try 6.5. Also, with core files, I have noticed that people sometimes
analyze them on a machine that's different from the one where the
core file was generated. Is this the case for you? If it is, chances
are the system libraries are slightly different, and that will cause
trouble during the backtrace computation.

Otherwise, you will probably need to specify at least the platform
on which you are running, but even then, I doubt that this will be
sufficient to help you. You probably need to provide a way for us
to reproduce your problem.

-- 
Joel

RE: Help: corrupt Stack

[Bizhan Gholikhamseh (bgholikh)]

Thanks for reply. ,
We are using cross compiler for Linux 2.6.11, our host is x86 system and
our target system is PPC based. I apologize if this is not enough
information, if there is anything else please let me know, however if
there are any hints that I should do to help me please let me know.

Many thanks in advance,
Bizhan

-----Original Message-----
From: Joel Brobecker [mailto:brobecker@adacore.com] 
Sent: Friday, July 14, 2006 9:20 PM
To: Bizhan Gholikhamseh (bgholikh)
Cc: gdb@sourceware.org
Subject: Re: Help: corrupt Stack

> We are using gdb version 6.3. When we ran gdb on the core dump 
> generated, it complains with following messages:
> "Previous frame identical to this frame (corrupt stack?)"
> Is this a known bug, is there a work around or patch available?

I am afraid you are not providing enough information for anyone to help
you here. 6.3 is pretty old at this point, so you should try 6.5. Also,
with core files, I have noticed that people sometimes analyze them on a
machine that's different from the one where the core file was generated.
Is this the case for you? If it is, chances are the system libraries are
slightly different, and that will cause trouble during the backtrace
computation.

Otherwise, you will probably need to specify at least the platform on
which you are running, but even then, I doubt that this will be
sufficient to help you. You probably need to provide a way for us to
reproduce your problem.

--
Joel

Re: Help: corrupt Stack

[Daniel Jacobowitz]

On Sat, Jul 15, 2006 at 10:27:19AM -0700, Bizhan Gholikhamseh (bgholikh) wrote:
> Thanks for reply. ,
> We are using cross compiler for Linux 2.6.11, our host is x86 system and
> our target system is PPC based. I apologize if this is not enough
> information, if there is anything else please let me know, however if
> there are any hints that I should do to help me please let me know.

Search for solib-absolute-prefix and make sure that your GDB knows
where to find PPC shared libraries.  That may help.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Help: corrupt Stack

[Mark Kettenis]

> Date: Fri, 14 Jul 2006 17:33:49 -0700
> From: "Bizhan Gholikhamseh \(bgholikh\)" <bgholikh@cisco.com>
> 
> Hi All,
> We are using gdb version 6.3. When we ran gdb on the core dump
> generated, it complains with following messages:
> "Previous frame identical to this frame (corrupt stack?)"
> Is this a known bug, is there a work around or patch
> available?

What makes you think this is a bug in GDB?  One of the possible
reasons your program dumped core could be because it did thrash the
stack.  Another possibility is that your code doesn't include enough
debug information or even wrong debug information, which confuses GDB
a bit.

Of course it is still possible that GDB is confused with itself
because there is a bug in its stack unwinding code.  But if you don't
give us more information, there's no way we can tell.

Mark