From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21883 invoked by alias); 3 Dec 2004 22:16:22 -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 21077 invoked from network); 3 Dec 2004 22:15:40 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 3 Dec 2004 22:15:40 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CaLi0-0003w3-Hp; Fri, 03 Dec 2004 17:15:24 -0500 Date: Fri, 03 Dec 2004 22:23:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203221524.GA15030@nevyn.them.org> Mail-Followup-To: Joel Brobecker , Andrew Cagney , gdb-patches@sources.redhat.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> <20041203215745.GL16491@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041203215745.GL16491@adacore.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00090.txt.bz2 On Fri, Dec 03, 2004 at 01:57:45PM -0800, Joel Brobecker wrote: > > >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. I'd suggest that you return a null frame ID from frame *5* actually. Is there a reason not to do that? Certainly a bit of caution is called for, but if GDB has the knowledge that a particular bit of code can never be backtraced through... There's an equivalent function in the glibc thread libraries for starting a thread, which should never be backtraced through. Note that we can't do a similar thing for clone unless the target's library provides a symbol distinct from clone to use; we have to be able to backtrace from clone itself. -- Daniel Jacobowitz