• Hi all, I’m working on fixing a data race in DWARFContext::getLineInfoForAddress ( Multithreading issue with DWARFContext::getLineInfoForAddress · Issue #167285 · llvm/llvm-project · GitHub ) and we have reached a design decision point where we’d like broader community input, especially from Sony and Apple folks who have performance sensitive use cases (like dsymutil). • Problem : When DWARFContext is created with ThreadSafe=true , there is still a race condition in DWARFUnit::tryExtractDIEsIfNeeded() . • Multiple threads can simultaneously follow cross-CU references (via DW_AT_abstract_origin or DW_AT_specification ), triggering lazy DIE extraction on the same DWARFUnit . • This causes crashes due to concurrent std::vector mutations. • ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED llvm::DWARFUnit::extractDIEsToVector(…) llvm::DWARFUnit::tryExtractDIEsIfNeeded(…) Interestingly, LLDB’s DWARFUnit already handles this correctly with a reader-writer mutex. • There are couple of approaches we stumbled on.

Article Summaries:

  • Hi all, I’m working on fixing a data race in DWARFContext::getLineInfoForAddress ( Multithreading issue with DWARFContext::getLineInfoForAddress · Issue #167285 · llvm/llvm-project · GitHub ) and we have reached a design decision point where we’d like broader community input, especially from Sony and Apple folks who have performance sensitive use cases (like dsymutil). Problem : When DWARFContext is created with ThreadSafe=true , there is still a race condition in DWARFUnit::tryExtractDIEsIfNeeded() . Multiple threads can simultaneously follow cross-CU references (via DW_AT_abstract_origin o

Sources: