From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10283 invoked by alias); 25 Apr 2003 00:18:41 -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 10276 invoked from network); 25 Apr 2003 00:18:41 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 25 Apr 2003 00:18:41 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h3P0IfD08980 for ; Thu, 24 Apr 2003 20:18:41 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3P0IeW27516; Thu, 24 Apr 2003 20:18:40 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h3P0IdM23660; Thu, 24 Apr 2003 17:18:39 -0700 Message-ID: <3EA87EDF.4A0826F8@redhat.com> Date: Fri, 25 Apr 2003 01:47:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com, cagney@redhat.com Subject: Re: crasher in dwarf2loc.c References: <3EA5E370.F069D062@redhat.com> <20030423021617.GB13849@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00480.txt.bz2 Daniel Jacobowitz wrote: > > On Tue, Apr 22, 2003 at 05:50:56PM -0700, Michael Snyder wrote: > > Hey Daniel, > > > > I've got a core dump coming from dwarf_expr_frame_base. > > First you call get_frame_function, and then you immediately > > use its return value. But get_frame_function can return zero, > > so I think you need to check for zero before using it. > > > > Michael > > Just to avoid the crash, you're probably right. > > > PS: more details: get_frame_block returns zero, because > > frame_address_in_block returns a pc that is not in any block. > > > > The crash occurs while running recurse.exp, when we have a > > watchpoint on a local variable in an inner frame, and we > > continue -- so I don't know the exact context; but I'm > > willing to bet that it is trying to evaluate the local > > variable after the stack frame has been destroyed. > > Huh - we should not even be reaching this code. I don't quite > understand your explanation; what target does this happen? Can it be > reproduced on a simulator, or something of that ilk? mumble, mumble... [...] mumble, mumble, mumble... OK, yes. But first you have to back out this change: then run recurse.exp. If it doesn't crash in your target of choice, try h8300-elf (sim). 2003-04-21 Andrew Cagney * frame.c (frame_id_eq): Fail when the code_addr's do not match. *************** frame_id_eq (struct frame_id l, struct f *** 295,304 **** /* The .stack and .code are identical, the ID's are identical. */ eq = 1; else ! /* FIXME: cagney/2003-04-06: This should be zero. Can't yet do ! this because most frame ID's are not being initialized ! correctly. */ ! eq = 1; if (frame_debug) { fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l="); --- 295,302 ---- /* The .stack and .code are identical, the ID's are identical. */ eq = 1; else ! /* No luck. */ ! eq = 0; if (frame_debug) { fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l=");