From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3398 invoked by alias); 3 Dec 2004 21:58:03 -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 3360 invoked from network); 3 Dec 2004 21:57:55 -0000 Received: from unknown (HELO priv-edtnes57.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 3 Dec 2004 21:57:55 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes57.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041203215750.XYMK16366.priv-edtnes57.telusplanet.net@takamaka.act-europe.fr>; Fri, 3 Dec 2004 14:57:50 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id A511A47DA6; Fri, 3 Dec 2004 13:57:45 -0800 (PST) Date: Fri, 03 Dec 2004 22:16:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203215745.GL16491@adacore.com> References: <20041202224606.GL994@adacore.com> <41B0AFED.5050803@gnu.org> <20041203184903.GH16491@adacore.com> <41B0BD9D.8040603@gnu.org> <20041203195741.GJ16491@adacore.com> <41B0DCFE.7010903@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B0DCFE.7010903@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00089.txt.bz2 > >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? We create the ID of this frame. Then create the previous frame. I think I'm starting to see how I was confused. Going back to my initial example, we have: #0 simple.break_me () at simple.adb:27 #1 0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21 #2 0x0000a268 in simple__callerB___2 () at simple.adb:18 #3 0x00017184 in system.tasking.stages.task_wrapper () #4 0x00017058 in system__tasking__stages__task_wrapper () #5 0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1 #6 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1 #7 0x00000000 in ?? () Imagine we are at frame #6, and try to go up one frame. So what happens is that we compute the ID of frame #6, and then, assuming all the sanity checks are ok, create frame #7. What you are suggesting is that we return a null frame ID for frame #6, correct? What I thought you were saying is that we return a null frame ID for frame *7*, which of course should never exist. > A null-ID indicates that the frame can't be unwound from, not that it is > necessarially itself invalid. I think that's the key I didn't understand. > There are two objectives here: > > - stop a run-away stack > which means correctly determining it's end This is the problem we're trying to solve. > - deciding, for possibly cosmetic reasons, which frames to list > which means stopping the list at main by default This part, I think, is fine. > 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. Absolutely. Thanks for the explanation! Hopefully I got it right this time. -- Joel