2cf69684fb
The cause of this crash is relatively simple -- we are using a SymbolFileDWARFDwo to parse a (skeleton) dwarf unit. This cause the CompileUnit to be created with the wrong ID, which later triggers an assertion in SymbolFile::SetCompileUnitAtIndex. The fix is also simple -- ensure we use the right symbol file for parsing. However, a fairly elaborate setup is needed trigger this bug, because ParseCompileUnit is normally called very early on (and with the right symbol file object) during the process of accessing a compile unit. The only way this can be triggered is if the DWARF unit is "accidentally" pulled into scope during expression evaluation This can happen if the "this" object used for the context of an expression is in a namespace, and that namespace is also present in other compile units The included test recreates this setup.
38 lines
988 B
C++
38 lines
988 B
C++
// This tests a crash which occured under very specific circumstances. The
|
|
// interesting aspects of this test are:
|
|
// - we print a global variable from one compile unit
|
|
// - we are stopped in a member function of a class in a namespace
|
|
// - that namespace is also present in a third file, which also has a global
|
|
// variable
|
|
|
|
// UNSUPPORTED: system-darwin, system-windows
|
|
|
|
// RUN: %clang_host -c -gsplit-dwarf %s -o %t1.o -DONE
|
|
// RUN: %clang_host -c -gsplit-dwarf %s -o %t2.o -DTWO
|
|
// RUN: %clang_host -c -gsplit-dwarf %s -o %t3.o -DTHREE
|
|
// RUN: %clang_host %t1.o %t2.o %t3.o -o %t
|
|
// RUN: %lldb %t -o "br set -n foo" -o run -o "p bool_in_first_cu" -o exit \
|
|
// RUN: | FileCheck %s
|
|
|
|
// CHECK: (lldb) p bool_in_first_cu
|
|
// CHECK: (bool) $0 = true
|
|
|
|
|
|
#if defined(ONE)
|
|
bool bool_in_first_cu = true;
|
|
#elif defined(TWO)
|
|
bool bool_in_second_cu = true;
|
|
|
|
namespace NS {
|
|
void f() {}
|
|
}
|
|
#elif defined(THREE)
|
|
namespace NS {
|
|
struct S {
|
|
void foo() {}
|
|
};
|
|
}
|
|
|
|
int main() { NS::S().foo(); }
|
|
#endif
|