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
test.s
Description: Binary data
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev