Skip to content

Cherry-pick LiveDebugValues bugfix #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Oct 30, 2019
Merged

Cherry-pick LiveDebugValues bugfix #57

merged 2 commits into from
Oct 30, 2019

Conversation

adrian-prantl
Copy link

rdar://problem/56363999

jmorse added 2 commits October 29, 2019 15:37
@jmorse @adrian-prantl
[DebugInfo] Avoid crash from dropped fragments in LiveDebugValues
35a654d 
This patch avoids a crash caused by DW_OP_LLVM_fragments being dropped
from DIExpressions by LiveDebugValues spill-restore code. The appearance
of a previously unseen fragment configuration confuses LDV, as documented
in PR42773, and reproduced by the test function this patch adds (Crashes
on a x86_64 debug build).

To avoid this, on spill restore, we now use fragment information from the
spilt-location-expression.

In addition, when spilling, we now don't spill any DBG_VALUE with a complex
expression, as it can't be safely restored and will definitely lead to an
incorrect variable location. The discussion of this is in D65368.

Differential Revision: https://reviews.llvm.org/D66284

llvm-svn: 369026
(cherry picked from commit c476124)
@jmorse @adrian-prantl
[DebugInfo] Avoid adding too much indirection to pointer-valued varia…
7a232b1 
…bles

This patch addresses PR41675, where a stack-pointer variable is dereferenced
too many times by its location expression, presenting a value on the stack as
the pointer to the stack.

The difference between a stack *pointer* DBG_VALUE and one that refers to a
value on the stack, is currently the indirect flag. However the DWARF backend
will also try to guess whether something is a memory location or not, based
on whether there is any computation in the location expression. By simply
prepending the stack offset to existing expressions, we can accidentally
convert a register location into a memory location, which introduces a
suprise (and unintended) dereference.

The solution is to add DW_OP_stack_value whenever we add a DIExpression
computation to a stack *pointer*. It's an implicit location computed on the
expression stack, thus needs to be flagged as a stack_value.

For the edge case where the offset is zero and the location could be a register
location, DIExpression::prepend will still generate opcodes, and thus
DW_OP_stack_value must still be added.

Differential Revision: https://reviews.llvm.org/D63429

llvm-svn: 364736
(cherry picked from commit d2b6665)
@adrian-prantl
Copy link
Author

@swift-ci test

1 similar comment
@adrian-prantl
Copy link
Author

@swift-ci test

@adrian-prantl adrian-prantl merged commit 008b8e1 into swiftlang:apple/stable/20190619 Oct 30, 2019
@adrian-prantl adrian-prantl deleted the 56363999 branch October 30, 2019 19:15
@adrian-prantl adrian-prantl mentioned this pull request Jul 20, 2020
Merged
@benlangmuir benlangmuir mentioned this pull request Oct 31, 2019
Closed
@trfiala trfiala mannequin mentioned this pull request Jul 21, 2016
Closed
@swift-ci swift-ci mentioned this pull request May 7, 2022
Open
adrian-prantl added a commit to adrian-prantl/llvm-project that referenced this pull request Jan 20, 2023
@adrian-prantl
Work around an infinite recursion with deadlock that only exists on
ba81700 
the swift branch.

The function IRExecutionUnit::PopulateSymtab() is only implemented in swift-lldb.

One thing it does is resolve any unresolved global symbols in the JIT
module. This global search can cause the JIT module to recursively be
asked for its symtab.

This patch works around the problem by removing the JIT module from
the list of modules being searched while in PopulateSymtab. That isn't
done in the most elegant fashion, as it does so by changing the state
of the IRExecutionUnit object.

(lldb) bt
* thread swiftlang#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10
    frame swiftlang#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242
    frame swiftlang#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70
    frame swiftlang#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
  * frame swiftlang#4: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame swiftlang#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame swiftlang#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt]
    frame swiftlang#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt]
    frame swiftlang#8: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame swiftlang#9: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b05a0, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame swiftlang#10: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame swiftlang#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame swiftlang#12: 0x000000014fe8c4c0 LLDB`lldb_private::Module::FindFunctions(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, lldb::FunctionNameType, lldb_private::ModuleFunctionSearchOptions const&, lldb_private::SymbolContextList&) at Module.cpp:857:29 [opt]
    frame swiftlang#13: 0x000000014fe8c4b0 LLDB`lldb_private::Module::FindFunctions(this=0x0000000106589ca0, name=<unavailable>, parent_decl_ctx=0x00007ff7bfef98d0, name_type_mask=eFunctionNameTypeFull, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) at Module.cpp:878:3 [opt]
    frame swiftlang#14: 0x000000014fe92ba1 LLDB`lldb_private::ModuleList::FindFunctions(this=<unavailable>, name=<unavailable>, name_type_mask=<unavailable>, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) const at ModuleList.cpp:554:18 [opt]
    frame swiftlang#15: 0x000000014fef36cb LLDB`lldb_private::IRExecutionUnit::FindInSymbols(this=<unavailable>, names=<unavailable>, sc=0x00000001004db950, symbol_was_missing_weak=<unavailable>) at IRExecutionUnit.cpp:843:33 [opt]
    frame swiftlang#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt]
    frame swiftlang#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt]
    frame swiftlang#18: 0x000000014fef4490 LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] lldb_private::IRExecutionUnit::MemoryManager::findSymbol(this=<unavailable>, Name=<unavailable>) at IRExecutionUnit.cpp:988:21 [opt]
    frame swiftlang#19: 0x000000014fef447d LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at IRExecutionUnit.cpp:0 [opt]
    frame swiftlang#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt]
    frame swiftlang#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt]
    frame swiftlang#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt]
    frame swiftlang#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt]
    frame swiftlang#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt]
    frame swiftlang#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt]
    frame swiftlang#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt]
    frame swiftlang#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt]
    frame swiftlang#28: 0x000000014ff93a14 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) at ObjectFile.cpp:764:9 [opt]
    frame swiftlang#29: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] decltype(__f=0x00007ff7bfefa180)::$_0>(fp)()) std::__1::__invoke<lldb_private::ObjectFile::GetSymtab()::$_0>(lldb_private::ObjectFile::GetSymtab()::$_0&&) at type_traits:3918:1 [opt]
    frame swiftlang#30: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] void std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::__execute<>(this=<unavailable>, (null)=<unavailable>) at mutex:630:9 [opt]
    frame swiftlang#31: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::operator(this=<unavailable>)() at mutex:622:9 [opt]
    frame swiftlang#32: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(__vp=<unavailable>) at mutex:658:5 [opt]
    frame swiftlang#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
    frame swiftlang#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
    frame swiftlang#35: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame swiftlang#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame swiftlang#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt]
    frame swiftlang#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt]
    frame swiftlang#39: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame swiftlang#40: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b0560, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame swiftlang#41: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame swiftlang#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame swiftlang#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt]
    frame swiftlang#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt]
    frame swiftlang#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt]
    frame swiftlang#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt]
    frame swiftlang#47: 0x00000001500284ca LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:1637:5 [opt]
    frame swiftlang#48: 0x00000001500284a7 LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:0 [opt]
    frame swiftlang#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt]
    frame swiftlang#50: 0x000000014fe91f44 LLDB`lldb_private::ModuleList::Append(this=0x000000010309eb48, module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, notify=<unavailable>) at ModuleList.cpp:339:3 [opt]
    frame swiftlang#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt]
    frame swiftlang#52: 0x000000015011063b LLDB`lldb_private::SwiftUserExpression::Parse(this=<unavailable>, diagnostic_manager=<unavailable>, exe_ctx=<unavailable>, execution_policy=eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=<unavailable>, generate_debug_info=<unavailable>) at SwiftUserExpression.cpp:802:28 [opt]
    frame swiftlang#53: 0x000000014ff0cd05 LLDB`lldb_private::UserExpression::Evaluate(exe_ctx=<unavailable>, options=0x00006000033441e0, expr="", prefix="", result_valobj_sp=nullptr, error=0x00007ff7bfefaf40, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at UserExpression.cpp:281:27 [opt]
    frame swiftlang#54: 0x000000015002e124 LLDB`lldb_private::Target::EvaluateExpression(this=0x000000010309e800, expr="", exe_scope=<unavailable>, result_valobj_sp=nullptr, options=<unavailable>, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at Target.cpp:2960:25 [opt]
    frame swiftlang#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt]
    frame swiftlang#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt]
    frame swiftlang#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]
adrian-prantl added a commit to adrian-prantl/llvm-project that referenced this pull request Jan 20, 2023
@adrian-prantl
Work around an infinite recursion with deadlock that only exists on
a8339d3 
the swift branch.

The function IRExecutionUnit::PopulateSymtab() is only implemented in swift-lldb.

One thing it does is resolve any unresolved global symbols in the JIT
module. This global search can cause the JIT module to recursively be
asked for its symtab.

This patch works around the problem by removing the JIT module from
the list of modules being searched while in PopulateSymtab. That isn't
done in the most elegant fashion, as it does so by changing the state
of the IRExecutionUnit object.

(lldb) bt
* thread swiftlang#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10
    frame swiftlang#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242
    frame swiftlang#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70
    frame swiftlang#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
  * frame swiftlang#4: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame swiftlang#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame swiftlang#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt]
    frame swiftlang#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt]
    frame swiftlang#8: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame swiftlang#9: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b05a0, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame swiftlang#10: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame swiftlang#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame swiftlang#12: 0x000000014fe8c4c0 LLDB`lldb_private::Module::FindFunctions(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, lldb::FunctionNameType, lldb_private::ModuleFunctionSearchOptions const&, lldb_private::SymbolContextList&) at Module.cpp:857:29 [opt]
    frame swiftlang#13: 0x000000014fe8c4b0 LLDB`lldb_private::Module::FindFunctions(this=0x0000000106589ca0, name=<unavailable>, parent_decl_ctx=0x00007ff7bfef98d0, name_type_mask=eFunctionNameTypeFull, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) at Module.cpp:878:3 [opt]
    frame swiftlang#14: 0x000000014fe92ba1 LLDB`lldb_private::ModuleList::FindFunctions(this=<unavailable>, name=<unavailable>, name_type_mask=<unavailable>, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) const at ModuleList.cpp:554:18 [opt]
    frame swiftlang#15: 0x000000014fef36cb LLDB`lldb_private::IRExecutionUnit::FindInSymbols(this=<unavailable>, names=<unavailable>, sc=0x00000001004db950, symbol_was_missing_weak=<unavailable>) at IRExecutionUnit.cpp:843:33 [opt]
    frame swiftlang#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt]
    frame swiftlang#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt]
    frame swiftlang#18: 0x000000014fef4490 LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] lldb_private::IRExecutionUnit::MemoryManager::findSymbol(this=<unavailable>, Name=<unavailable>) at IRExecutionUnit.cpp:988:21 [opt]
    frame swiftlang#19: 0x000000014fef447d LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at IRExecutionUnit.cpp:0 [opt]
    frame swiftlang#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt]
    frame swiftlang#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt]
    frame swiftlang#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt]
    frame swiftlang#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt]
    frame swiftlang#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt]
    frame swiftlang#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt]
    frame swiftlang#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt]
    frame swiftlang#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt]
    frame swiftlang#28: 0x000000014ff93a14 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) at ObjectFile.cpp:764:9 [opt]
    frame swiftlang#29: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] decltype(__f=0x00007ff7bfefa180)::$_0>(fp)()) std::__1::__invoke<lldb_private::ObjectFile::GetSymtab()::$_0>(lldb_private::ObjectFile::GetSymtab()::$_0&&) at type_traits:3918:1 [opt]
    frame swiftlang#30: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] void std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::__execute<>(this=<unavailable>, (null)=<unavailable>) at mutex:630:9 [opt]
    frame swiftlang#31: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::operator(this=<unavailable>)() at mutex:622:9 [opt]
    frame swiftlang#32: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(__vp=<unavailable>) at mutex:658:5 [opt]
    frame swiftlang#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
    frame swiftlang#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
    frame swiftlang#35: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt]
    frame swiftlang#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame swiftlang#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt]
    frame swiftlang#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt]
    frame swiftlang#39: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt]
    frame swiftlang#40: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b0560, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt]
    frame swiftlang#41: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt]
    frame swiftlang#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame swiftlang#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt]
    frame swiftlang#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt]
    frame swiftlang#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt]
    frame swiftlang#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt]
    frame swiftlang#47: 0x00000001500284ca LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:1637:5 [opt]
    frame swiftlang#48: 0x00000001500284a7 LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:0 [opt]
    frame swiftlang#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt]
    frame swiftlang#50: 0x000000014fe91f44 LLDB`lldb_private::ModuleList::Append(this=0x000000010309eb48, module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, notify=<unavailable>) at ModuleList.cpp:339:3 [opt]
    frame swiftlang#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt]
    frame swiftlang#52: 0x000000015011063b LLDB`lldb_private::SwiftUserExpression::Parse(this=<unavailable>, diagnostic_manager=<unavailable>, exe_ctx=<unavailable>, execution_policy=eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=<unavailable>, generate_debug_info=<unavailable>) at SwiftUserExpression.cpp:802:28 [opt]
    frame swiftlang#53: 0x000000014ff0cd05 LLDB`lldb_private::UserExpression::Evaluate(exe_ctx=<unavailable>, options=0x00006000033441e0, expr="", prefix="", result_valobj_sp=nullptr, error=0x00007ff7bfefaf40, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at UserExpression.cpp:281:27 [opt]
    frame swiftlang#54: 0x000000015002e124 LLDB`lldb_private::Target::EvaluateExpression(this=0x000000010309e800, expr="", exe_scope=<unavailable>, result_valobj_sp=nullptr, options=<unavailable>, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at Target.cpp:2960:25 [opt]
    frame swiftlang#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt]
    frame swiftlang#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt]
    frame swiftlang#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]

(cherry picked from commit ba81700)
adrian-prantl pushed a commit that referenced this pull request May 5, 2023
@Michael137
[lldb][TypeSystem] ForEach: Don't hold the TypeSystemMap lock across …
ac6d5b1 
…callback

The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.

`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:

```

int main() {
    std::unique_ptr<int> up = std::make_unique<int>(5);

    volatile int val = *up;
    return val;
}

clang++ -std=c++2a -g -O1 main.cpp

./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```

```
frame #4: std::lock_guard<std::mutex>::lock_guard
frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2
frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame #27: lldb_private::SwiftASTContext::LoadModule
frame #30: swift::ModuleDecl::collectLinkLibraries
frame #31: lldb_private::SwiftASTContext::LoadModule
frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame #38: lldb_private::Target::GetPersistentSymbol
frame #41: lldb_private::TypeSystemMap::ForEach                 <<<< Lock #1
frame #42: lldb_private::Target::GetPersistentSymbol
frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame #44: lldb_private::IRExecutionUnit::FindSymbol
frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #48: llvm::LinkingSymbolResolver::findSymbol
frame #49: llvm::LegacyJITSymbolResolver::lookup
frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame #51: llvm::RuntimeDyldImpl::resolveRelocations
frame #52: llvm::MCJIT::finalizeLoadedModules
frame #53: llvm::MCJIT::finalizeObject
frame #54: lldb_private::IRExecutionUnit::ReportAllocations
frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame #56: lldb_private::ClangExpressionParser::PrepareForExecution
frame #57: lldb_private::ClangUserExpression::TryParse
frame #58: lldb_private::ClangUserExpression::Parse
```

Our solution is to simply iterate over a local copy of `m_map`.

**Testing**

* Confirmed on manual reproducer (would reproduce 100% of the time
  before the patch)

Differential Revision: https://reviews.llvm.org/D149949

(cherry picked from commit dda3a6a)
swift-ci pushed a commit that referenced this pull request May 5, 2023
@Michael137
[lldb][TypeSystem] ForEach: Don't hold the TypeSystemMap lock across …
e74f03d 
…callback

The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.

`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:

```

int main() {
    std::unique_ptr<int> up = std::make_unique<int>(5);

    volatile int val = *up;
    return val;
}

clang++ -std=c++2a -g -O1 main.cpp

./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```

```
frame #4: std::lock_guard<std::mutex>::lock_guard
frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2
frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame #27: lldb_private::SwiftASTContext::LoadModule
frame #30: swift::ModuleDecl::collectLinkLibraries
frame #31: lldb_private::SwiftASTContext::LoadModule
frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame #38: lldb_private::Target::GetPersistentSymbol
frame #41: lldb_private::TypeSystemMap::ForEach                 <<<< Lock #1
frame #42: lldb_private::Target::GetPersistentSymbol
frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame #44: lldb_private::IRExecutionUnit::FindSymbol
frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #48: llvm::LinkingSymbolResolver::findSymbol
frame #49: llvm::LegacyJITSymbolResolver::lookup
frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame #51: llvm::RuntimeDyldImpl::resolveRelocations
frame #52: llvm::MCJIT::finalizeLoadedModules
frame #53: llvm::MCJIT::finalizeObject
frame #54: lldb_private::IRExecutionUnit::ReportAllocations
frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame #56: lldb_private::ClangExpressionParser::PrepareForExecution
frame #57: lldb_private::ClangUserExpression::TryParse
frame #58: lldb_private::ClangUserExpression::Parse
```

Our solution is to simply iterate over a local copy of `m_map`.

**Testing**

* Confirmed on manual reproducer (would reproduce 100% of the time
  before the patch)

Differential Revision: https://reviews.llvm.org/D149949
@kendalharland kendalharland mentioned this pull request Aug 8, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@adrian-prantl @jmorse