From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23938 invoked by alias); 3 Dec 2004 21:40:38 -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 23833 invoked from network); 3 Dec 2004 21:40:33 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Dec 2004 21:40:33 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB3LeSHg012717 for ; Fri, 3 Dec 2004 16:40:33 -0500 Received: from localhost.redhat.com (vpn50-46.rdu.redhat.com [172.16.50.46]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB3LeSr18231; Fri, 3 Dec 2004 16:40:28 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6C6CF96A08; Fri, 3 Dec 2004 16:39:13 -0500 (EST) Message-ID: <41B0DCFE.7010903@gnu.org> Date: Fri, 03 Dec 2004 21:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... References: <20041202224606.GL994@adacore.com> <41B0AFED.5050803@gnu.org> <20041203184903.GH16491@adacore.com> <41B0BD9D.8040603@gnu.org> <20041203195741.GJ16491@adacore.com> In-Reply-To: <20041203195741.GJ16491@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00084.txt.bz2 Joel Brobecker wrote: >>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. Which ID, this or prev? GDB computes this-ID does some sanity checks and then, assuming it is valid, blindly creates prev 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? A null-ID indicates that the frame can't be unwound from, not that it is necessarially itself invalid. I think you're describing the old logic: if (prev frame ID valid) then return prev frame it had the problem that it wasn't possible to examine that terminal, possibly corrupt, frame. I deleted the test (and there was much celebration :-). There are two objectives here: - stop a run-away stack which means correctly determining it's end - deciding, for possibly cosmetic reasons, which frames to list which means stopping the list at main by default when it comes to the true outer-most frame there's always going to be fuz, as long as it terminates I think we're ok. Andrew