Re: [commit] dwarf2read.c (load_partial_dies): Change condition to assert.

[Doug Evans <dje at google dot com>]

On Sat, Apr 7, 2012 at 2:46 PM, Michael Eager <eager@eagerm.com> wrote:
> age_cached_comp_units() is called to age the CU cache and free up
> cached CUs which were not recently used. ?This happens while reading
> symbols for a different CU.

Right, but such calls won't happen between the time cu->per_cu is set
and load_partial_dies is called (unless I've missed something of
course).

>> My reading of all of the callers says it can't happen (modulo bugs of
>> course).
>> I could have missed something of course (in which case let's get
>> something added to the testsuite to exercise the appropriate code
>> path).
>
>
> My concern is that unless the per_cu data was loaded by one of the
> immediate callers, it may have been flushed.

I welcome someone reviewing the callers and showing what I missed.

I know of no case where a struct dwarf2_cu exists without its
corresponding struct dwarf2_per_cu_data.

> I'm not sure I can create a reasonable test case for this problem.
> I ran into this with a large program with many CUs printing a struct
> which took several pages to print. ?The per_cu data disappeared in
> the middle of printing the struct.

I think we need to be careful with terminology here (gdb sometimes
doesn't make this easy though).
There's per_cu and there's per_cu->cu.
per_cu (i.e. struct dwarf2_per_cu_data) does not get flushed or aged.
per_cu->cu (i.e. struct dwarf2_cu) does.

In your case did a struct dwarf2_per_cu_data disappear, or was it per_cu->cu?

I have no doubt there are bugs in this area, btw.