Re: innermost_block-related crash

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Jul 18, 2006 at 01:32:00AM +0200, Mark Kettenis wrote:
> The backtrace is a bit confusing since frame #1 is in a yacc source
> file, but what it boils down to is that innermost_block is a dangling
> pointer.  This seems to be related to the fact that the test rereads
> the symbols.  Since blocks are generally allocated using the objfile
> obstack, this could indeed explain the dangling pointer; the old
> objfile was freed, so the obstack isn't there anymore.  And if you're
> on a system with a randomizing memory allocator, the obstack for the
> new objfile is likely to be in a totally different region of memory.
> 
> I'm not sure how to solve this.  Should we simply always set
> innermost_block to NULL when we start evaluating a new expression?  Or
> should we do that as part of freeing an objfile.  The root of the
> problem of course is the abuse of a global variable, but passing down
> state through the entire expression evaluation chain imples some major
> surgery :(.

I'd recommend moving the initialization into parse_expression.  But
that's going to require figuring out whether there are any calls where
we don't want to reset it, e.g. recursively...

-- 
Daniel Jacobowitz
CodeSourcery