From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9078 invoked by alias); 23 Feb 2009 00:49:02 -0000 Received: (qmail 9066 invoked by uid 22791); 23 Feb 2009 00:49:02 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Feb 2009 00:48:53 +0000 Received: (qmail 2210 invoked from network); 23 Feb 2009 00:48:48 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Feb 2009 00:48:48 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH] PR backtrace/9786 Date: Mon, 23 Feb 2009 01:08:00 -0000 User-Agent: KMail/1.9.10 Cc: Joel Brobecker , Nick Roberts References: <18849.13514.379735.375860@kahikatea.snap.net.nz> <20090223001651.GA26056@adacore.com> In-Reply-To: <20090223001651.GA26056@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902230048.52805.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00423.txt.bz2 Nick Roberts wrote: > (gdb) target remote localhost:4444 > Remote debugging using localhost:4444 > 0xb7fda810 in ?? () from /lib/ld-linux.so.2 > (gdb) info frame > Stack level 0, frame at 0x0: I'm guessing that i386 unwinder is noticing that ebp is 0 and deciding this is the outermost frame. The amd64 unwinder seems to handle this a bit different, and will probably end up thinking that this is a frameless function. i386-tdep.c has this: i386_frame_cache () { (...) get_frame_register (this_frame, I386_EBP_REGNUM, buf); cache->base = extract_unsigned_integer (buf, 4); if (cache->base == 0) return cache; (...) > eip = 0xb7fda810; saved eip > findvar.c:299: internal-error: value_of_register_lazy: Assertion `frame_id_p > (get_frame_id (frame))' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) On Monday 23 February 2009 00:16:51, Joel Brobecker wrote: > What do others think? This internal error sounds suspiciously related to the fact that there's no current way to distinguish a null/invalid frame id, from an outermost frame id... We should really fix that sometime. -- Pedro Alves