Skip to content
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.

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

MoveChecker causes false positives with no way to fix #46

Closed
mattiasj-axis opened this issue Nov 27, 2019 · 2 comments
Closed

MoveChecker causes false positives with no way to fix #46

mattiasj-axis opened this issue Nov 27, 2019 · 2 comments
Assignees

Comments

@mattiasj-axis
Copy link

As a dumb example

#include <utility>
struct Foo {
    Foo() {}
    Foo(Foo&&o) { o._is_valid = false; }
    bool is_valid() { return _is_valid; }
private:
    bool _is_valid = true;
};

int main() {
    Foo a;
    Foo b{std::move(a)};

    if (a.is_valid()) { return 0; } else { return 1; }
}

Where is_valid is actually a check if this object is usable, the MoveChecker is hardcoded to assume that this function must be called [is]empty. This should presumably be an attribute, such as clang::movesafe so that functions that are coded movesafe can be tagged properly.

Likewise, clang::movestatereset or something like such should be introduced for functions that reset the state (but I haven't had that issue, yet).

@llvmbot
Copy link
Collaborator

llvmbot commented Apr 12, 2022

@llvm/issue-subscribers-clang-static-analyzer

@haoNoQ
Copy link
Collaborator

haoNoQ commented Apr 12, 2022

While I agree that such attributes could be helpful, I'm really curious how does the original use case rule out the possibility to simply create a new local variable instead of reusing the storage. In the vastly typical scenario there's simply no incentive to deal with the complexity of storage reuse when local variables are basically free and the moved-from object is typically empty enough to not provide any reuse value.

Note that for the non-local variables this check simply doesn't fire; it only fires on non-locals when the class is standard and the semantics of every method are known and the moved-from state is explicitly known to be hazardous, eg. dereference of moved smart pointer (known to be null) or pattern-matching a moved-from string (known to be in unspecified state).

@haoNoQ haoNoQ self-assigned this Apr 12, 2022
@martong martong closed this as completed May 27, 2022
@martong martong closed this as not planned Won't fix, can't repro, duplicate, stale May 27, 2022
jamesmth pushed a commit to jamesmth/llvm-project that referenced this issue Dec 5, 2022
* [AArch64] Fix mismatch in prologue and epilogue for funclets on Windows

The generated code for a funclet can have an add to sp in the epilogue
for which there is no corresponding sub in the prologue.

This patch removes the early return from emitPrologue that was
preventing the sub to sp, and instead conditionalizes the appropriate
parts of the rest of the function.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45345

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

* [AArch64] Change AArch64 Windows EH UnwindHelp object to be a fixed object

The UnwindHelp object is used during exception handling by runtime
code. It must be findable from a fixed offset from FP.

This change allocates the UnwindHelp object as a fixed object (as is
done for x86_64) to ensure that both the generated code and runtime
agree on the location of the object.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45346

Differential Revision: https://reviews.llvm.org/D77016
augusto2112 pushed a commit to augusto2112/llvm-project that referenced this issue Jan 23, 2023
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 llvm#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10
    frame llvm#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242
    frame llvm#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70
    frame llvm#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
  * frame llvm#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 llvm#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#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 llvm#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt]
    frame llvm#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt]
    frame llvm#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 llvm#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 llvm#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt]
    frame llvm#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt]
    frame llvm#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt]
    frame llvm#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt]
    frame llvm#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt]
    frame llvm#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt]
    frame llvm#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt]
    frame llvm#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#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 llvm#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 llvm#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
    frame llvm#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
    frame llvm#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 llvm#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt]
    frame llvm#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt]
    frame llvm#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt]
    frame llvm#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt]
    frame llvm#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 llvm#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 llvm#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt]
    frame llvm#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 llvm#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt]
    frame llvm#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt]
    frame llvm#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]
augusto2112 pushed a commit to augusto2112/llvm-project that referenced this issue Jan 23, 2023
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 llvm#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10
    frame llvm#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242
    frame llvm#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70
    frame llvm#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
  * frame llvm#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 llvm#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#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 llvm#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt]
    frame llvm#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt]
    frame llvm#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 llvm#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 llvm#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt]
    frame llvm#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt]
    frame llvm#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt]
    frame llvm#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt]
    frame llvm#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt]
    frame llvm#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt]
    frame llvm#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt]
    frame llvm#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#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 llvm#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 llvm#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139
    frame llvm#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt]
    frame llvm#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 llvm#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt]
    frame llvm#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt]
    frame llvm#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt]
    frame llvm#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt]
    frame llvm#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt]
    frame llvm#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt]
    frame llvm#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt]
    frame llvm#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 llvm#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 llvm#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt]
    frame llvm#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 llvm#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt]
    frame llvm#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 llvm#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 llvm#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 llvm#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt]
    frame llvm#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt]
    frame llvm#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]

(cherry picked from commit ba81700)
trevor-m pushed a commit to trevor-m/llvm-project that referenced this issue Apr 20, 2023
There is a SIGSEGV at `DeduceTemplateArgumentsByTypeMatch`. The bug [llvm#51171](https://bugs.llvm.org/show_bug.cgi?id=51171) was filled. The reproducer can be found at the bug description.

LIT test for the issue was added:
```
./bin/llvm-lit -v ../clang/test/SemaCXX/pr51171-crash.cpp
```

The debug stack trace is below:
```
 #0 0x00000000055afcb9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:22
 llvm#1 0x00000000055afd70 PrintStackTraceSignalHandler(void*) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1
 llvm#2 0x00000000055add2d llvm::sys::RunSignalHandlers() /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Signals.cpp:97:20
 llvm#3 0x00000000055af701 SignalHandler(int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1
 llvm#4 0x00007ffff7bc2b20 __restore_rt sigaction.c:0:0
 llvm#5 0x00007ffff66a337f raise (/lib64/libc.so.6+0x3737f)
 llvm#6 0x00007ffff668ddb5 abort (/lib64/libc.so.6+0x21db5)
 llvm#7 0x00007ffff668dc89 _nl_load_domain.cold.0 loadmsgcat.c:0:0
 llvm#8 0x00007ffff669ba76 .annobin___GI___assert_fail.end assert.c:0:0
 llvm#9 0x000000000594b210 clang::QualType::getCommonPtr() const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/Type.h:684:5
llvm#10 0x0000000005a12ca6 clang::QualType::getCanonicalType() const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/Type.h:6467:36
llvm#11 0x0000000005a137a6 clang::ASTContext::getCanonicalType(clang::QualType) const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/ASTContext.h:2433:58
llvm#12 0x0000000009204584 DeduceTemplateArgumentsByTypeMatch(clang::Sema&, clang::TemplateParameterList*, clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:1355:54
llvm#13 0x000000000920df0d clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, clang::QualType, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4354:47
llvm#14 0x0000000009012b09 (anonymous namespace)::AddressOfFunctionResolver::AddMatchingTemplateFunction(clang::FunctionTemplateDecl*, clang::DeclAccessPair const&) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12026:38
llvm#15 0x0000000009013030 (anonymous namespace)::AddressOfFunctionResolver::FindAllFunctionsThatMatchTargetTypeExactly() /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12119:9
llvm#16 0x0000000009012679 (anonymous namespace)::AddressOfFunctionResolver::AddressOfFunctionResolver(clang::Sema&, clang::Expr*, clang::QualType const&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:11931:5
llvm#17 0x0000000009013c91 clang::Sema::ResolveAddressOfOverloadedFunction(clang::Expr*, clang::QualType, bool, clang::DeclAccessPair&, bool*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12286:42
llvm#18 0x0000000008fed85d IsStandardConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, clang::StandardConversionSequence&, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:1712:49
llvm#19 0x0000000008fec8ea TryImplicitConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, clang::Sema::AllowedExplicit, bool, bool, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:1433:27
llvm#20 0x0000000008ff90ba TryCopyInitialization(clang::Sema&, clang::Expr*, clang::QualType, bool, bool, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:5273:71
llvm#21 0x00000000090024fb clang::Sema::AddBuiltinCandidate(clang::QualType*, llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&, bool, unsigned int) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:7755:32
llvm#22 0x000000000900513f (anonymous namespace)::BuiltinOperatorOverloadBuilder::addGenericBinaryArithmeticOverloads() /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:8633:30
llvm#23 0x0000000009007624 clang::Sema::AddBuiltinOperatorCandidates(clang::OverloadedOperatorKind, clang::SourceLocation, llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:9205:51
llvm#24 0x0000000009018734 clang::Sema::LookupOverloadedBinOp(clang::OverloadCandidateSet&, clang::OverloadedOperatorKind, clang::UnresolvedSetImpl const&, llvm::ArrayRef<clang::Expr*>, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:13469:1
llvm#25 0x0000000009018d56 clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*, bool, bool, clang::FunctionDecl*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:13568:24
llvm#26 0x0000000008b24797 BuildOverloadedBinOp(clang::Sema&, clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14606:65
llvm#27 0x0000000008b24ed5 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14691:73
llvm#28 0x0000000008b245d4 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14566:1
llvm#29 0x00000000085bfafb clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*, true>, clang::prec::Level) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:630:71
llvm#30 0x00000000085bd922 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:177:1
llvm#31 0x00000000085cbbcd clang::Parser::ParseExpressionList(llvm::SmallVectorImpl<clang::Expr*>&, llvm::SmallVectorImpl<clang::SourceLocation>&, llvm::function_ref<void ()>) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:3368:40
llvm#32 0x000000000857f49c clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseDecl.cpp:2416:5
llvm#33 0x000000000857df16 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseDecl.cpp:2092:65
llvm#34 0x000000000855f07b clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:1138:1
llvm#35 0x000000000855f136 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:1153:57
llvm#36 0x000000000855e644 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:975:58
llvm#37 0x000000000855d717 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:720:42
llvm#38 0x0000000008558e01 clang::ParseAST(clang::Sema&, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseAST.cpp:158:37
llvm#39 0x000000000627a221 clang::ASTFrontendAction::ExecuteAction() /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1058:11
llvm#40 0x0000000006bdcc31 clang::CodeGenAction::ExecuteAction() /home/ivanmurashko/local/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:1045:5
llvm#41 0x0000000006279b4d clang::FrontendAction::Execute() /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/FrontendAction.cpp:955:38
llvm#42 0x00000000061c3fe9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:974:42
llvm#43 0x00000000063f9c5e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/ivanmurashko/local/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:38
llvm#44 0x0000000002603a03 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /home/ivanmurashko/local/llvm-project/clang/tools/driver/cc1_main.cpp:246:40
llvm#45 0x00000000025f8a39 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /home/ivanmurashko/local/llvm-project/clang/tools/driver/driver.cpp:338:20
llvm#46 0x00000000025f9107 main /home/ivanmurashko/local/llvm-project/clang/tools/driver/driver.cpp:415:26
llvm#47 0x00007ffff668f493 __libc_start_main (/lib64/libc.so.6+0x23493)
llvm#48 0x00000000025f729e _start (/data/users/ivanmurashko/llvm-project/build/bin/clang-13+0x25f729e)
```

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D106583
Michael137 added a commit to Michael137/llvm-project that referenced this issue May 5, 2023
…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 llvm#4: std::lock_guard<std::mutex>::lock_guard
frame llvm#5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock llvm#2
frame llvm#6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame llvm#7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame llvm#26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame llvm#27: lldb_private::SwiftASTContext::LoadModule
frame llvm#30: swift::ModuleDecl::collectLinkLibraries
frame llvm#31: lldb_private::SwiftASTContext::LoadModule
frame llvm#34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame llvm#35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame llvm#36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame llvm#37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame llvm#38: lldb_private::Target::GetPersistentSymbol
frame llvm#41: lldb_private::TypeSystemMap::ForEach                 <<<< Lock llvm#1
frame llvm#42: lldb_private::Target::GetPersistentSymbol
frame llvm#43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame llvm#44: lldb_private::IRExecutionUnit::FindSymbol
frame llvm#45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame llvm#46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame llvm#47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame llvm#48: llvm::LinkingSymbolResolver::findSymbol
frame llvm#49: llvm::LegacyJITSymbolResolver::lookup
frame llvm#50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame llvm#51: llvm::RuntimeDyldImpl::resolveRelocations
frame llvm#52: llvm::MCJIT::finalizeLoadedModules
frame llvm#53: llvm::MCJIT::finalizeObject
frame llvm#54: lldb_private::IRExecutionUnit::ReportAllocations
frame llvm#55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame llvm#56: lldb_private::ClangExpressionParser::PrepareForExecution
frame llvm#57: lldb_private::ClangUserExpression::TryParse
frame llvm#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
Michael137 added a commit to Michael137/llvm-project that referenced this issue May 5, 2023
…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 llvm#4: std::lock_guard<std::mutex>::lock_guard
frame llvm#5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock llvm#2
frame llvm#6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame llvm#7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame llvm#26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame llvm#27: lldb_private::SwiftASTContext::LoadModule
frame llvm#30: swift::ModuleDecl::collectLinkLibraries
frame llvm#31: lldb_private::SwiftASTContext::LoadModule
frame llvm#34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame llvm#35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame llvm#36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame llvm#37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame llvm#38: lldb_private::Target::GetPersistentSymbol
frame llvm#41: lldb_private::TypeSystemMap::ForEach                 <<<< Lock llvm#1
frame llvm#42: lldb_private::Target::GetPersistentSymbol
frame llvm#43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame llvm#44: lldb_private::IRExecutionUnit::FindSymbol
frame llvm#45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame llvm#46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame llvm#47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame llvm#48: llvm::LinkingSymbolResolver::findSymbol
frame llvm#49: llvm::LegacyJITSymbolResolver::lookup
frame llvm#50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame llvm#51: llvm::RuntimeDyldImpl::resolveRelocations
frame llvm#52: llvm::MCJIT::finalizeLoadedModules
frame llvm#53: llvm::MCJIT::finalizeObject
frame llvm#54: lldb_private::IRExecutionUnit::ReportAllocations
frame llvm#55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame llvm#56: lldb_private::ClangExpressionParser::PrepareForExecution
frame llvm#57: lldb_private::ClangUserExpression::TryParse
frame llvm#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)
Michael137 added a commit that referenced this issue May 5, 2023
…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
zhanyi22333 pushed a commit to zhanyi22333/llvm-project that referenced this issue Mar 7, 2024
…s from 1.0 to xtheadvector (llvm#46)

* [Clang][XTHeadVector] Add intrinsic wrapper macros

in order to compatible with RVV 1.0

* [Clang][XTHeadVector] Test intrinsic wrapper macros
RevySR pushed a commit to revyos/llvm-project that referenced this issue Apr 3, 2024
…s from 1.0 to xtheadvector (llvm#46)

* [Clang][XTHeadVector] Add intrinsic wrapper macros

in order to compatible with RVV 1.0

* [Clang][XTHeadVector] Test intrinsic wrapper macros
JonChesterfield pushed a commit to JonChesterfield/llvm-project that referenced this issue Apr 17, 2024
rewrite make_generated_offload_arch script in Python
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants