Re: SEGV in dwarf2read.c -- gdb-7.2

[Michael Eager <eager@eagerm.com>]

On 11/03/2011 09:20 AM, Jan Kratochvil wrote:
> Hello Michael,
>
> sorry but I cannot comment more without a reproducer, such possible fix should
> have a regression testcase anyway.  Could you provide a reproducer in some
> form even just off-list (so that I can reduce it if it is not completely
> public and not so critically secure)?

I don't think I can.  The application is proprietary.  I not sure that I
can create an artificial test case with a structure containing hundreds of
members and multiple compilation units which might trigger the SEGV.

> On Thu, 03 Nov 2011 17:12:08 +0100, Michael Eager wrote:
>> I ran into a SEGV in in gdb-7.2
>
> The stable release is 7.3.1, moreover for such development I would find only
> FSF GDB HEAD relevant.  I remember several fixes which it may be related to.

Can't help that.  Bugs are found on the tools in use, not necessarily
the latest release.

>> Is there a reason to read the CU header into a temporary data
>> area rather than reload it using load_full_comp_unit() which will add it to
>> the CU cache?
>
> I guess for performance reasons, the CU header read-in vs. load_full_comp_unit
> is a big difference.  There are already some PRs (such as 12828 (a)) where GDB
> needlessly expands too many CUs "locking itself" by inacceptable performance.

It seems that this would cause the CU header to be read many times, when
it would otherwise use the cache.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077