This is an archive of the discontinued LLVM Phabricator instance.

Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked
ClosedPublic

Authored by jankratochvil on Oct 14 2018, 6:50 AM.

Details

Summary

xbolva00 bugreported $subj
It can happen only from the line:

m_die_array.back().SetEmptyChildren(true);

In the case DW_TAG_compile_unit has DW_CHILDREN_yes but there is only 0 (end of list, no children present). Therefore the assertion can fortunately happen only with a hand-crafted DWARF or with DWARF from some suboptimal compilers.
I could not find a reproducer with unpatched LLDB code, could you provide what LLDB commands could reproduce that? A debuggee binary which can reproduce it is: lldb-repro.tar.xz

Diff Detail

Repository
rL LLVM

Event Timeline

jankratochvil created this revision.Oct 14 2018, 6:50 AM

reproducer archive - 404 not found

jankratochvil edited the summary of this revision. (Show Details)Oct 14 2018, 10:11 AM

reproducer archive - 404 not found

Fixed, sorry.

In our case (yes, we have some "additional dwarf", we are gonna fix it on our side), it crashed with "process launch -s".

xbolva00 accepted this revision.Oct 15 2018, 12:00 AM

assert fix looks fine

This revision is now accepted and ready to land.Oct 15 2018, 12:00 AM

Out of curiosity: why do we allow for both an empty array and an empty children sentinel? Is that distinction useful?

This revision was automatically updated to reflect the committed changes.

Out of curiosity: why do we allow for both an empty array and an empty children sentinel? Is that distinction useful?

Filed for that new D53321.

It looks like it should be easy to write a test for this by hand-crafting a minimal .s file and feeding it to lldb-test.

It looks like it should be easy to write a test for this by hand-crafting a minimal .s file and feeding it to lldb-test.

Even with such a crafted file (in lldb-repro.tar.xz) I haven't found a way how to call DWARFUnit::ExtractUnitDIEIfNeeded() first. LLDB will always call DWARFUnit::ExtractDIEsRWLocked() first which cannot reproduce the bug. @xbolva00's file must have something special that process launch -s does call DWARFUnit::ExtractUnitDIEIfNeeded() first, my testcase does not. As I guess @xbolva00 cannot provide that file to us I think it would be enough to see a backtrace to the first call of DWARFUnit::ExtractUnitDIEIfNeeded() to find it out.