This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]