This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: innermost_block-related crash
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb at sourceware dot org
- Date: Thu, 20 Jul 2006 17:35:37 -0400
- Subject: Re: innermost_block-related crash
- References: <200607172332.k6HNW05R006835@elgar.sibelius.xs4all.nl>
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