LLDB regression in 11.6

Xcode LLDB Regression

  • We are seeing that LLDB takes a very long time to execute the set breakpoint command with Xcode 11.6.
  • I compared LLDB b/w Xcode 11.2.1 and Xcode 11.6. It seems that the LLDB team has changed the DWARF Debug line parser during this time which is causing slowness than before.
  • Based on my understanding of the source code ( which is very little ) https://reviews.llvm.org/D62570 is what caused the regression

LLDB shipped with Xcode 11.2.1

LLDB shipped with Xcode 11.6

You can find the Instruments trace file here

Please let us know if anyone else sees this.

2 Likes

I believe we're hitting this as well, one of our developers looked into this a bit and got the following stack trace when hitting a breakpoint with a locally built lldb:

From the following part of the stack trace it appears that the non-dSYM DWARF loader calls GetTypeSystemForLanguage for Swift which triggers Clang modules to be built. Using dSYMS seems to workaround this regression (presumably by avoiding this call) but at the cost of slower incremental builds.

    frame #16: 0x000000011b1982c3 LLDB`swift::MemoryBufferSerializedModuleLoader::loadModule(this=0x00007fb7f0138dd0, importLoc=<unavailable>, path=<unavailable>) at SerializedModuleLoader.cpp:925:8 [opt]
    frame #17: 0x000000011b3084a4 LLDB`swift::ASTContext::getModuleByName(llvm::StringRef) at ASTContext.cpp:1756:35 [opt]
    frame #18: 0x000000011b30844d LLDB`swift::ASTContext::getModuleByName(this=0x00007fb7e35a3600, ModuleName=(Data = 0x0000000000000000, Length = 0)) at ASTContext.cpp:1772 [opt]
    frame #19: 0x000000011a0e9ae5 LLDB`lldb_private::SwiftASTContext::GetModule(this=0x00007fb7e5631620, module=0x00007ffee2b14930, error=0x00007ffee2b148f8) at SwiftASTContext.cpp:3761:41 [opt]
    frame #20: 0x000000011a0e5fca LLDB`lldb_private::SwiftASTContext::ValidateSectionModules(this=0x00007fb7e5631620, module=0x00007fb8b2c20ac8, module_names=<unavailable>) at SwiftASTContext.cpp:4349:10 [opt]
    frame #21: 0x000000011a0e2418 LLDB`lldb_private::SwiftASTContext::CreateInstance(language=<unavailable>, module=<unavailable>, target=<unavailable>, fallback=<unavailable>) at SwiftASTContext.cpp:1795:19 [opt]
    frame #22: 0x000000011a0e8aeb LLDB`CreateTypeSystemInstance(language=<unavailable>, module=<unavailable>, target=<unavailable>, extra_options=<unavailable>) at SwiftASTContext.cpp:2264:12 [opt]
    frame #23: 0x000000011a0d1b76 LLDB`lldb_private::TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType, lldb_private::Module*, bool) at TypeSystem.cpp:59:9 [opt]
    frame #24: 0x000000011a0d1b32 LLDB`lldb_private::TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType, lldb_private::Module*, bool) [inlined] lldb_private::TypeSystem::CreateInstance(language=eLanguageTypeSwift, module=0x00007fb8b2c20ac8) at TypeSystem.cpp:69 [opt]
    frame #25: 0x000000011a0d1b32 LLDB`lldb_private::TypeSystemMap::GetTypeSystemForLanguage(this=<unavailable>, language=<unavailable>, module=0x00007fb8b2c20ac8, can_create=<unavailable>) at TypeSystem.cpp:299 [opt]
    frame #26: 0x0000000119fa67fe LLDB`lldb_private::Module::GetTypeSystemForLanguage(this=<unavailable>, language=<unavailable>) at Module.cpp:360:28 [opt]
    frame #27: 0x000000011a0c3b94 LLDB`lldb_private::SymbolFile::GetTypeSystemForLanguage(this=0x00007fb8b2c0b0c0, language=<unavailable>) at SymbolFile.cpp:95:34 [opt]
    frame #28: 0x000000011a4965c7 LLDB`SymbolFileDWARF::GetTypeSystemForLanguage(this=0x00007fb7f546d400, language=<unavailable>) at SymbolFileDWARF.cpp:436:31 [opt]
    frame #29: 0x000000011a4980d4 LLDB`SymbolFileDWARF::ParseFunction(this=0x00007fb7f546d400, comp_unit=0x00007fb7e562f9b8, die=0x00007ffee2b15128) at SymbolFileDWARF.cpp:805:7 [opt]
    frame #30: 0x000000011a49d1a6 LLDB`SymbolFileDWARF::ResolveSymbolContext(this=0x00007fb7f546d400, so_addr=0x00007ffee2b15190, resolve_scope=eSymbolContextEverything, sc=0x00007ffee2b15310) at SymbolFileDWARF.cpp:1874:33 [opt]
    frame #31: 0x000000011a4acc66 LLDB`SymbolFileDWARFDebugMap::ResolveSymbolContext(this=0x00007fb8b2c0b0c0, exe_so_addr=<unavailable>, resolve_scope=eSymbolContextEverything, sc=0x00007ffee2b15310) at SymbolFileDWARFDebugMap.cpp:791:48 [opt]
    frame #32: 0x0000000119fa6c99 LLDB`lldb_private::Module::ResolveSymbolContextForAddress(this=0x00007fb8b2c20ac8, so_addr=0x00007ffee2b153b0, resolve_scope=eSymbolContextEverything, sc=0x00007ffee2b15310, resolve_tail_call_address=false) at Module.cpp:472:20 [opt]
    frame #33: 0x0000000119f7137b LLDB`lldb_private::Address::CalculateSymbolContext(this=0x00007ffee2b153b0, sc=0x00007ffee2b15310, resolve_scope=eSymbolContextEverything) const at Address.cpp:808:31 [opt]

I think there might be two issues here?

  • Possible regression in lldb due to GetLineTable
  • lldb eagerly creating SwiftASTContexts

See the SymbolFileDWARF call which ends up calling through to Swift. I wonder if the call to Swift can be avoided or if the Swift call can defer the work until later.

Went ahead and opened https://bugs.swift.org/browse/SR-13719 for this

Hey,

The patch you linked indeed introduced a regression. The issue was related to how we parse the support files.

Prior to my patch of using the LLVM line table parsing code, SymbolFileDWARF::ParseSupportFiles would only parse the line table prologues to get the file list for any files that could be in the line table. If we found the file that someone is setting the breakpoint in in the support files list, we would get a valid index. If we didn't, we would not look any further. So someone sets a breakpoint one "MyFile.cpp:12" and if we find "MyFile.cpp" in the support file list for the compile unit, then and only then would we get the entire line table for that compile unit. Now, no matter what, we always fully parse the line table for all compile units any time any file and line breakpoint is set. This creates a serious problem when debugging a large DWARF in .o file project.

This has since been fixed by https://reviews.llvm.org/D81589 which we shipped in Xcode 12.

@DavidGoldman which version of Xcode is in use for your issues? Note that GetTypeSystemForLanguage doesn't show up as a slow issue in @tapthaker's instruments trace, so whatever you're seeing appears to be a different issue.

Thank you, good to know :slightly_smiling_face:

I just reproduced this issue personally with a Swift app with Xcode 12, trace file here. Updated https://bugs.swift.org/browse/SR-13719 to link to my trace

Terms of Service

Privacy Policy

Cookie Policy