From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4770 invoked by alias); 5 Mar 2008 20:42:24 -0000 Received: (qmail 4761 invoked by uid 22791); 5 Mar 2008 20:42:24 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Mar 2008 20:42:06 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 4B4213C33A; Wed, 5 Mar 2008 12:42:05 -0800 (PST) Subject: Re: Previous frame identical to this frame (corrupt stack?) From: Michael Snyder To: Guillaume MENANT Cc: gdb@sourceware.org In-Reply-To: <15854428.post@talk.nabble.com> References: <15854428.post@talk.nabble.com> Content-Type: text/plain Date: Thu, 06 Mar 2008 02:05:00 -0000 Message-Id: <1204749725.19253.640.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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/msg00056.txt.bz2 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.