From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25989 invoked by alias); 3 Dec 2004 19:57:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25966 invoked from network); 3 Dec 2004 19:57:43 -0000 Received: from unknown (HELO priv-edtnes46.telusplanet.net) (199.185.220.240) by sourceware.org with SMTP; 3 Dec 2004 19:57:43 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes46.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041203195742.RYQG8516.priv-edtnes46.telusplanet.net@takamaka.act-europe.fr>; Fri, 3 Dec 2004 12:57:42 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 2B89D47DA6; Fri, 3 Dec 2004 11:57:41 -0800 (PST) Date: Fri, 03 Dec 2004 20:19:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203195741.GJ16491@adacore.com> References: <20041202224606.GL994@adacore.com> <41B0AFED.5050803@gnu.org> <20041203184903.GH16491@adacore.com> <41B0BD9D.8040603@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B0BD9D.8040603@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00082.txt.bz2 > Yes, gdb already creates the frame object and then later constructs the > frame ID. The build has been reduced to: > > prev_frame = malloc (); > prev_frame->next = this_frame; > return prev_frame; > > Also note that, unlike the past, the frame ID is separate to the ``frame > base'' the former can be NULL while the later is still valid. > > >And then, after building each new frame, we display the information > >for that new frame. > > It is what lets us "up" on to an apparently corrupt frame. Reviewing the code that does the backtrace, I don't see how this would work. We're at the oldest frame, trying to unwind from it. So we compute its ID, and then create the previous frame. I didn't find where in our code, in particular in stack.c, we're prepared to deal with a frame that we later find is invalid (via a null frame ID). Perhaps it is simpler to modify the build sequence above to add the computation of the frame ID and use that as a guard before creating the new frame? -- Joel