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

[lldb/Host] Remove TaskPool and replace its uses with llvm::ThreadPool #1576

Merged
merged 2 commits into from
Aug 3, 2020
Merged

[lldb/Host] Remove TaskPool and replace its uses with llvm::ThreadPool #1576

merged 2 commits into from
Aug 3, 2020

Conversation

JDevlieghere
Copy link

Remove LLDB's TaskPool and replace its uses with LLVM's ThreadPool.

Differential revision: https://reviews.llvm.org/D78337

(cherry picked from commit e57361c)

Remove LLDB's TaskPool and replace its uses with LLVM's ThreadPool.

Differential revision: https://reviews.llvm.org/D78337

(cherry picked from commit e57361c)
@JDevlieghere
Copy link
Author

@swift-ci please test

Copy link

@varungandhi-apple varungandhi-apple left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! 😄

@JDevlieghere
Copy link
Author

I don't see the REPL test timeouts locally and I can't think of any reason this change would cause that. Let's try again...

@swift-ci please test platform macos

@JDevlieghere
Copy link
Author

@swift-ci please test macos platform

@JDevlieghere
Copy link
Author

After a few tries I was able to repro this. It appears like a legit deadlock. We're waiting on the module mutex in ObjectFileMachO::ParseHeader().

frame #4: 0x000000011583308f LLDB`ObjectFileMachO::ParseHeader() 
frame #5: 0x0000000115833087 LLDB`ObjectFileMachO::ParseHeader() 
frame #6: 0x0000000115833087 LLDB`ObjectFileMachO::ParseHeader(...) at ObjectFileMachO.cpp:984 [opt]
frame #7: 0x00000001158312a7 LLDB`ObjectFileMachO::CreateInstance(...) at ObjectFileMachO.cpp:801:35 [opt]
frame #8: 0x000000011556ec0b LLDB`lldb_private::ObjectFile::FindPlugin(...) at ObjectFile.cpp:137:32 [opt]
frame #9: 0x0000000115959fff LLDB`SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(...) at SymbolFileDWARF.cpp:1723:31 [opt]
frame #10: 0x000000011594618b LLDB`DWARFUnit::AddUnitDIE(...) at DWARFUnit.cpp:340:15 [opt]
frame #11: 0x00000001159469c1 LLDB`DWARFUnit::ExtractDIEsRWLocked(...) at DWARFUnit.cpp:184:9 [opt]
frame #12: 0x0000000115946db0 LLDB`DWARFUnit::ExtractDIEsScoped(...) at DWARFUnit.cpp:107:3 [opt]

I'll need to do a debug build to be sure, but I suspect it's the same module as the one held by the SymbolFileDWARF instance where we call SymbolFileDWARF::FindFunctions.

frame #5: 0x000000011594d9c2 LLDB`lldb_private::ManualDWARFIndex::Index(...) at ManualDWARFIndex.cpp:72:8 [opt]
frame #6: 0x000000011594eb90 LLDB`lldb_private::ManualDWARFIndex::GetFunctions(...), dwarf=0x00007fd8c6221e00, parent_decl_ctx=0x0000700001fb58c0, name_type_mask=4, dies=size=0) at ManualDWARFIndex.cpp:361:3 [opt]
frame #7: 0x000000011595cd24 LLDB`SymbolFileDWARF::FindFunctions(...) at SymbolFileDWARF.cpp:2449:12 [opt]
frame #8: 0x00000001154830dc LLDB`lldb_private::Module::FindFunctions(...), parent_decl_ctx=0x0000000000000000, name_type_mask=eFunctionNameTypeFull, include_symbols=true, include_inlines=false, sc_list=0x0000700001fb5af8) at Module.cpp:849:16 [opt]
frame #9: 0x0000000115488416 LLDB`lldb_private::ModuleList::FindFunctions(...) const at ModuleList.cpp:410:15 [opt]
frame #10: 0x00000001154e545c LLDB`lldb_private::IRExecutionUnit::FindInSymbols(...) at IRExecutionUnit.cpp:880:33 [opt]
frame #11: 0x00000001154e5781 LLDB`lldb_private::IRExecutionUnit::FindSymbol(...) at IRExecutionUnit.cpp:960:22 [opt]
frame #12: 0x00000001154e5fad LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(...) at IRExecutionUnit.cpp:1063:31 [opt]

This was already worked around in rdar://problem/38461035, but it was lost in
a follow-up merge resolution. This reinstates the workaround and adds a test
(from https://bugs.swift.org/browse/SR-7114) to make sure we don't regress this.

apple-llvm-split-commit: ac73e28ffd7b156abbc6a9b3b62db0ba3b4c46f2
apple-llvm-split-dir: lldb/
(cherry picked from commit 510589b)
@JDevlieghere
Copy link
Author

@swift-ci please test

@JDevlieghere JDevlieghere merged commit ab0a317 into swiftlang:swift/master Aug 3, 2020
@JDevlieghere JDevlieghere deleted the 🍒/e57361c055d7617ee25cdac8167625000d098ef5 branch August 3, 2020 23:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants