From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6155 invoked by alias); 3 Nov 2003 21:34:17 -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 6119 invoked from network); 3 Nov 2003 21:34:16 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 3 Nov 2003 21:34:16 -0000 Received: by zenia.home (Postfix, from userid 5433) id 6CA83207B3; Mon, 3 Nov 2003 16:33:44 -0500 (EST) To: Daniel Jacobowitz , Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Macro code crasher on re-run References: <20031103040751.GA30979@nevyn.them.org> <20031103045601.GA32557@nevyn.them.org> <20031103210453.GA17444@nevyn.them.org> From: Jim Blandy Date: Mon, 03 Nov 2003 21:34:00 -0000 In-Reply-To: <20031103210453.GA17444@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00016.txt.bz2 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.