JDevlieghere added a comment.
My first observations:
- We call `ResolveTypeUID` without going through the symbol vendor (similar to
`GetDeclContextForUID` in the stack trace). This is easy to fix, just add
locking to these functions.
- The module in the symbol vendor is different from the one in the symbol file.
This seems more tricky and I'm not sure if this expected?
I looked at TestCallCPPFunction where my newly added assertion triggered in
`ParseCompileUnitSupportFiles` which I found odd since we're taking the module
lock in symbol vendor.
frame #4: 0x000000010590c083
_lldb.so`lldb_private::SymbolFile::AssertModuleLock(this=0x000000010388ac00) at
SymbolFile.cpp:160
157 // We assert that we have to module lock by trying to acquire the
lock from a
158 // different thread. Note that we must abort if the result is true
to
159 // guarantee correctness.
-> 160 assert(std::async(
161 std::launch::async,
162 [this] {
163 return
this->GetObjectFile()->GetModule()->GetMutex().try_lock();
(lldb) p GetObjectFile()->GetModule()
(lldb::ModuleSP) $1 =
std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000118905378
strong=1 weak=1 {
__ptr_ = 0x0000000118905378
}
(lldb) fr sel 7
frame #7: 0x000000010591035b
_lldb.so`lldb_private::SymbolVendor::ParseCompileUnitSupportFiles(this=0x0000000100184f90,
sc=0x00007ffeefbf79a8, support_files=0x0000000118904d70) at
SymbolVendor.cpp:171
168 if (module_sp) {
169 std::lock_guard<std::recursive_mutex>
guard(module_sp->GetMutex());
170 if (m_sym_file_ap.get())
-> 171 return m_sym_file_ap->ParseCompileUnitSupportFiles(sc,
support_files);
172 }
173 return false;
174 }
(lldb) p module_sp
(lldb::ModuleSP) $0 =
std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000100189ec0
strong=6 weak=18 {
__ptr_ = 0x0000000100189ec0
}
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52543
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
