From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31485 invoked by alias); 3 Dec 2004 22:23:59 -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 31434 invoked from network); 3 Dec 2004 22:23:53 -0000 Received: from unknown (HELO priv-edtnes46.telusplanet.net) (199.185.220.240) by sourceware.org with SMTP; 3 Dec 2004 22:23:53 -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 <20041203222352.ZZZO8516.priv-edtnes46.telusplanet.net@takamaka.act-europe.fr>; Fri, 3 Dec 2004 15:23:52 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id ABD6B47DA6; Fri, 3 Dec 2004 14:23:51 -0800 (PST) Date: Fri, 03 Dec 2004 22:25:00 -0000 From: Joel Brobecker To: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203222351.GM16491@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> <20041203215745.GL16491@adacore.com> <20041203221524.GA15030@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041203221524.GA15030@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00091.txt.bz2 > > #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... Do you mean by checking the procedure name against "__pthread_create_system"? This should certainly be very easy to do. This is, on the other hand, OS specific. So this check should only be made when the OS is HPUX. -- Joel