From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11466 invoked by alias); 6 Mar 2008 06:54:53 -0000 Received: (qmail 11457 invoked by uid 22791); 6 Mar 2008 06:54:52 -0000 X-Spam-Check-By: sourceware.org Received: from kuber.nabble.com (HELO kuber.nabble.com) (216.139.236.158) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Mar 2008 06:54:27 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JX9zk-00009x-Ci for gdb@sourceware.org; Wed, 05 Mar 2008 22:54:24 -0800 Message-ID: <15867580.post@talk.nabble.com> Date: Thu, 06 Mar 2008 07:06:00 -0000 From: Guillaume MENANT To: gdb@sourceware.org Subject: Re: Previous frame identical to this frame (corrupt stack?) In-Reply-To: <1204749725.19253.640.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: guillaume.menant@geensys.com References: <15854428.post@talk.nabble.com> <1204749725.19253.640.camel@localhost.localdomain> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00059.txt.bz2 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.