From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6526 invoked by alias); 3 Nov 2003 04:56:02 -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 6519 invoked from network); 3 Nov 2003 04:56:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 3 Nov 2003 04:56:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AGWkz-0008Tb-HT; Sun, 02 Nov 2003 23:56:01 -0500 Date: Mon, 03 Nov 2003 04:56:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: Macro code crasher on re-run Message-ID: <20031103045601.GA32557@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: <20031103040751.GA30979@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/msg00006.txt.bz2 On Sun, Nov 02, 2003 at 11:48:05PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > There's a bug in default_macro_scope. > > Only one?!? :) One at a time, one at a time. > > > 97 > > 98 /* If all else fails, fall back to the current listing position. */ > > 99 else > > 100 { > > 101 /* Don't call select_source_symtab here. That can raise an > > 102 error if symbols aren't loaded, but GDB calls the expression > > 103 evaluator in all sorts of contexts. > > 104 > > 105 For example, commands like `set width' call the expression > > 106 evaluator to evaluate their numeric arguments. If the > > 107 current language is C, then that may call this function to > > 108 choose a scope for macro expansion. If you don't have any > > 109 symbol files loaded, then get_current_or_default would raise an > > 110 error. But `set width' shouldn't raise an error just because > > 111 it can't decide which scope to macro-expand its argument in. */ > > 112 struct symtab_and_line cursal = > > 113 get_current_source_symtab_and_line (); > > 114 > > 115 sal.symtab = cursal.symtab; > > 116 sal.line = cursal.line; > > 117 } > > > > So we initialize just the symtab and line pointers. > > 118 > > 119 return sal_macro_scope (sal); > > 120 } > > > > > > 39 if (! sal.symtab > > 40 || ! sal.symtab->macro_table) > > 41 return 0; > > > > Oops, uninitialized memory read. That else case can't work; Jim, should we > > just return 0 from default_macro_scope if the target isn't running, or > > is there a function I don't see somewhere to find the macrotab and > > initialize the rest of the symtab? Should it be "sal = cursal"? > > 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer