This is the mail archive of the
mailing list for the GDB project.
Re: SEGV in dwarf2read.c -- gdb-7.2
On 11/03/2011 09:20 AM, Jan Kratochvil wrote:
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 firstname.lastname@example.org
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077