From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15843 invoked by alias); 6 Mar 2008 09:24:40 -0000 Received: (qmail 15835 invoked by uid 22791); 6 Mar 2008 09:24:39 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Mar 2008 09:24:21 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1) with ESMTP id m269OGLt015716; Thu, 6 Mar 2008 10:24:16 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id m269OFDm022269; Thu, 6 Mar 2008 10:24:15 +0100 (CET) Date: Thu, 06 Mar 2008 10:05:00 -0000 Message-Id: <200803060924.m269OFDm022269@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@specifix.com CC: guillaume.menant@geensys.com, gdb@sourceware.org In-reply-to: <1204749725.19253.640.camel@localhost.localdomain> (msnyder@specifix.com) Subject: Re: Previous frame identical to this frame (corrupt stack?) References: <15854428.post@talk.nabble.com> <1204749725.19253.640.camel@localhost.localdomain> 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/msg00063.txt.bz2 > From: "Michael Snyder" > 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