From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8344 invoked by alias); 3 Nov 2003 21:37:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8325 invoked from network); 3 Nov 2003 21:37:07 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 3 Nov 2003 21:37:07 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AGmNm-0005KG-IC; Mon, 03 Nov 2003 16:37:06 -0500 Date: Mon, 03 Nov 2003 21:37:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: Macro code crasher on re-run Message-ID: <20031103213706.GA20445@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , gdb@sources.redhat.com References: <20031103040751.GA30979@nevyn.them.org> <20031103045601.GA32557@nevyn.them.org> <20031103210453.GA17444@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00017.txt.bz2 On Mon, Nov 03, 2003 at 04:33:44PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Mon, Nov 03, 2003 at 03:59:41PM -0500, Jim Blandy wrote: > > > > > > Daniel Jacobowitz writes: > > > > > I don't follow. All default_macro_scope's callers check for null > > > > > return; it's documented to return zero at times. So you must be > > > > > talking about that code in sal_macro_scope itself. Line 39 refers to > > > > > sal.symtab, initialized by line 115, so you must be talking about line > > > > > 40. But sal.symtab must be non-zero, or else we wouldn't reach the > > > > > right operand of the ||. > > > > > > > > > > Or should I sleep and try again? > > > > > > > > > > > > > Right. sal.symtab is nonzero. sal.symtab->macro_table, however, is > > > > uninitialized. The short-circuit if on line 40 does not trigger, but > > > > the remainder of sal_macro_scope assumes that sal.symtab->macro_table > > > > is valid. > > > > > > > > In my case it happens to be 0xB. > > > > > > Every symtab's macro_table field should be initialized, at least to > > > zero. Which symtab is it? Who creates it? > > > > If you thought I wasn't making sense, you were right. I really needed > > some sleep when I wrote that. > > > > My best guess is that the returned symtab belongs to the old (already > > unloaded) binary. Which would put the bug somewhere else. > > I haven't debugged it (only Daniel J. has seen the problem, as far as > I know), but I kind of suspect this change: > > 2003-10-22 Andrew Cagney > > * target.c (target_close): New function. > (debug_to_close): Use "target_close". > (push_target): Use "target_close". > (unpush_target): Use "target_close". > (pop_target): Use "target_close". > * target.h (struct target_ops): Add "to_xclose". > (target_open): Delete macro. Move comment to "to_open". > (target_close): Replace macro with function that takes a target. > * top.c (quit_target): Pass "current_target" to "target_close". > > The to_close method of the "exec" target calls free_objfile, which > assumes that its callers call clear_symtab_users at some appropriate > time. This change seems to have introduced several new callers to > target_close, so it may have broken that assumption. > > Having free_objfile require its callers to take care of things this > way is not very nice. I was using the 6.0 branch when I found the problem, so that's not it. It may be a related problem in a caller of free_objfile, though. Or reread_objfile? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer