[lldb-dev] Help fixing deadlock in DWARF symbol preloading
Jorge Gorbe Moya via lldb-dev
lldb-dev at lists.llvm.org
Thu Feb 4 12:04:50 PST 2021
Hi,
I've found a deadlock in lldb (see attached test case, you can build it
with just `clang -o test test.s`), but I'm a total newbie and I have no
idea what's the right way to fix it.
The problem happens when an error is found during DIE extraction when
preloading symbols. As far as I can tell, it goes like this:
1. Module::PreloadSymbols locks Module::m_mutex
2. A few layers below it, we end up in ManualDWARFIndex::Index, which
dispatches DIE extractions to a thread pool:
for (size_t i = 0; i < units_to_index.size(); ++i)
pool.async(extract_fn, i);
pool.wait();
3. extract_fn in the snippet above ends up executing
DWARFDebugInfoEntry::Extract and when there's an error during extraction,
Module::GetDescription is called while generating the error message.
4. Module::GetDescription tries to acquire Module::m_mutex from a different
thread, while the main thread has the mutex already locked and it's waiting
for DIE extraction to end, causing a deadlock.
If we make Module::GetDescription not lock the problem disappears, so the
diagnosis looks correct, but I don't know what would be the right way to
fix it. Module::GetDescription looks more or less safe to call without
locking: it just prints m_arch, m_file, and m_object_name to a string, and
those look like fields that wouldn't change after the Module is
initialized, so maybe it's okay? But I feel like there must be a better
solution anyway. Any advice?
Best,
Jorge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210204/af0da312/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.s
Type: application/octet-stream
Size: 4931 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210204/af0da312/attachment.obj>
More information about the lldb-dev
mailing list