From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18259 invoked by alias); 3 Dec 2004 18:20: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 18018 invoked from network); 3 Dec 2004 18:20:51 -0000 Received: from unknown (HELO priv-edtnes57.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 3 Dec 2004 18:20:51 -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 <20041203182050.LZPD16366.priv-edtnes57.telusplanet.net@takamaka.act-europe.fr>; Fri, 3 Dec 2004 11:20:50 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id DFC1247DA6; Fri, 3 Dec 2004 10:20:49 -0800 (PST) Date: Fri, 03 Dec 2004 18:20:00 -0000 From: Joel Brobecker To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203182049.GF16491@adacore.com> References: <20041202231255.GM994@adacore.com> <20041203024314.GR6359@tausq.org> <20041203025737.GT994@adacore.com> <20041203045252.GU6359@tausq.org> <20041203165430.GC16491@adacore.com> <20041203180324.GE6359@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041203180324.GE6359@tausq.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00073.txt.bz2 > argh, i was wrong... the stub unwinder handles the case when pc == 0, > and then it assumes that the rp doesn't get modified by default. OK. > there's also a bug in the outer __pthread_create_system frame; the stub > unwinder doesn't set the rp appropriately. can you try the attached > patch? it should convert your infinite backtrace into an error ;-) I gave it a try. I see the error, but a bit too early. That's because I have a stub in the middle of my call stack. Here is what I get now: (gdb) bt #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 0x0000a268 in simple__callerB___2 () at simple.adb:18 warning: Previous frame identical to this frame (corrupt stack?) (this was with 6.3, do you think HEAD would behave better?) -- Joel