> On Apr 28, 2016, at 8:11 AM, Philippe Lavoie <philippe.lav...@octasic.com> > wrote: > > > What made me suspect a data corruption issue were asserts triggered in the > VC++ vector implementation when we use an LTO binary with a DEBUG lldb build > on Windows. > > For example, > at source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:624, > > File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\vector > Line: 240 > Expression: vector iterators incompatible > > Digging deeper, the assertion is triggered by accesses to > DWARFCompileUnit::m_die_array > > In the 'parser_fn' lambda in SymbolFileDWARF::Index() that indexes each > compile unit in parallel, DWARFCompileUnit::ExtractDIEsIfNeeded(..) , > DWARFCompileUnit::Index(..) and DWARFCompileUnit::ClearDIEs() are called in > sequence. > > 'ExtractDIEsIfNeeded' and 'ClearDIEs' respectively populates and clears > DWARFCompileUnit::m_die_array. > > But when DWARFCompileUnit::Index(..) looks up a DIE in another CU and that CU > is running 'ExtractDIEsIfNeeded' or 'ClearDIEs', it will access a stale or > invalid DWARFCompileUnit::m_die_array ...
So the main question is why is anything that is indexing the current CU only, accessing anything from another CU? It can't and shouldn't. That is the bug. > -Philippe > > ________________________________________ > From: Greg Clayton [gclay...@apple.com] > Sent: Monday, April 25, 2016 7:59 PM > To: Philippe Lavoie > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] LTO debug info > >> On Apr 25, 2016, at 1:37 PM, Philippe Lavoie via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> Hello, >> >> We noticed an issue with dwarf parsing when debugging a large application >> compiled with LTO. >> >> Since an LTO application's debug info can have inter-compile-unit >> references, (for example: a type defined in one compile-unit and used in >> another) we noticed that the "m_type_index" vector in SymbolFileDWARF can >> get corrupted. This is because many index structures in SymbolFileDWARF are >> generated in parallel. >> >> Is is a bug or is it expected to be the compiler's/linker's job to generate >> self-contained DWARF data without inter-CU references? >> >> -Philippe > > TEach SymbolFileDWARF should generate its own accelerator tables in a self > contained way. No SymbolFileDWARF should be adding references to their > accelerator maps that actually refer to DIEs from another SymbolFileDWARF. We > might need to look at the indexing function that make sure if they see and > DW_FORM_ref_addr attributes, that they don't add any of them to their index. > That seems like the bug? > > Greg > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
