SEGV in dwarf2read.c -- gdb-7.2
Michael Eager
eager@eagerm.com
Thu Nov 3 16:12:00 GMT 2011
I ran into a SEGV in in gdb-7.2 in dwarf_expr_eval() (actually one of the
functions it calls) which is called from dwarf2_evaluate_loc_desc_full().
This was caused by the per_cu->cu==NULL.
The circumstances which triggered this SEGV is printing a huge structure
(four or five pages of output) followed by a backtrace. While printing
the struct, dwarf2_fetch_die_location_block() is called multiple times,
which calls age_cached_comp_units() which removes CU data from the cache.
When doing the backtrace, location descriptions are referenced and eventually
a NULL per_cu->cu is dereferenced.
I created the attached patch fixes the problem in gdb-7.2 by adding a new
function dwarf2_read_comp_unit_if_needed() which reloads the CU data and
adds it to the cache. I also modified dwarf2_per_cu_addr_size() and
dwarf2_per_cu_addr_size() to use this function rather than read the CU
header into a temporary.
When I tried to apply this to the head, I discovered that these functions
had been refactored adding a function per_cu_header_read_in() which read
in the CU header into a temporary.
I can rework the patch to exclude the conflicting changes, but this raises
a question: 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 noticed that a TRY_CATCH was added to dwarf2_evaluate_loc_desc_full()
which would catch this SEGV, but (it seems to me, incorrectly) indicate that
debug data was not available.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-cu-segv.patch
Type: text/x-patch
Size: 3370 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20111103/6d0a46d2/attachment.bin>
More information about the Gdb-patches
mailing list