zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-04 02:18:37 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

follow up to fix for 339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...

Browse Source 
The fix committed in revision 14603 is properly fixing the bug 339721.
However, when enabling the dwarf tracing, the DW_FORM_ref_sig8 causes
a segmentation violation, as the tracing code is shared with the
reading code. But the DW_FORM_ref_sig8 reading code is dereferencing
some data structure that is only initialised when --read-var-info=yes.

So, in case DW_FORM_ref_sig8 form reading is done and --read-var-info=no,
then check that we are tracing, and avoid dereferencing the (not initialised)
signature hash table.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14610
This commit is contained in:
Philippe Waroquiers 2014-10-07 20:35:06 +00:00
parent 97dc435677
commit 2e547da1ca
2 changed files with 24 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
NEWS
View File

@ -35,7 +35,7 @@ where XXXXXX is the bug number as listed below.
339182 ppc64: AvSplat ought to load destination vector register with 16/16
bytes stored prior
339433 ppc64 lxvw4x instruction uses four 32-byte loads
(not fully fixed yet) 339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...
339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...
n-i-bz Old STABS code is still being compiled, but never used. Remove it.
n-i-bz Fix compilation on distros with glibc < 2.5

28
coregrind/m_debuginfo/readdwarf3.c
View File

@ -1371,11 +1371,29 @@ void get_Form_contents ( /*OUT*/FormContents* cts,
TRACE_D3("%x ", (UInt)u8);
work >>= 8;
}
/* Due to the way that the hash table is constructed, the
resulting DIE offset here is already "cooked". See
cook_die_using_form. */
cts->u.val = lookup_signatured_type (cc->signature_types, signature,
c->barf);
/* cc->signature_types is only built/initialised when
VG_(clo_read_var_info) is set. In this case,
the DW_FORM_ref_sig8 can be looked up.
But we can also arrive here when only reading inline info
and VG_(clo_trace_symtab) is set. In such a case,
we cannot lookup the DW_FORM_ref_sig8, we rather assign
a dummy value. This is a kludge, but otherwise,
the 'dwarf inline info reader' tracing would have to
do type processing/reading. It is better to avoid
adding significant 'real' processing only due to tracing. */
if (VG_(clo_read_var_info)) {
/* Due to the way that the hash table is constructed, the
resulting DIE offset here is already "cooked". See
cook_die_using_form. */
cts->u.val = lookup_signatured_type (cc->signature_types, signature,
c->barf);
} else {
vg_assert (td3);
vg_assert (VG_(clo_read_inline_info));
TRACE_D3("<not dereferencing signature type>");
cts->u.val = 0; /* Assign a dummy/rubbish value */
}
cts->szB = sizeof(UWord);
break;
}