[lldb] [Windows] Lldb-dap crashes when trying to step over breakpoint

[ktraunmueller]

I have a swift-winrt based Windows desktop app.

Debugging works fine in the app executable, but when trying to step over (some, not all) breakpoints in other modules (see Package.swift below), the debugger crashes with

Assertion failed: Out.empty(), file D:\r\_work\swift-build\swift-build\SourceCache\llvm-project\llvm\lib\Support\ConvertUTFWrapper.cpp, line 85
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: E:\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin\\lldb-dap.exe
Exception Code: 0x80000003
 #0 0x00007ff7caa94b10 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x64b10)
 #1 0x00007ffb5b47b030 (C:\WINDOWS\System32\ucrtbase.dll+0x7b030)
 #2 0x00007ffb5b47bc3c (C:\WINDOWS\System32\ucrtbase.dll+0x7bc3c)
 #3 0x00007ffb5b47d5d4 (C:\WINDOWS\System32\ucrtbase.dll+0x7d5d4)
 #4 0x00007ffb5b47cbe0 (C:\WINDOWS\System32\ucrtbase.dll+0x7cbe0)
 #5 0x00007ffb5b47d70c (C:\WINDOWS\System32\ucrtbase.dll+0x7d70c)
 #6 0x00007ffa86d13628 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\liblldb.dll+0xcd3628)
 #7 0x00007ffa86a94108 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\liblldb.dll+0xa54108)
 #8 0x00007ffa862fc978 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\liblldb.dll+0x2bc978)
 #9 0x00007ff7caa6bfa0 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x3bfa0)
#10 0x00007ff7caa520bc (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x220bc)
#11 0x00007ff7caa5be08 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x2be08)
#12 0x00007ff7caa5c220 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x2c220)
#13 0x00007ff7caa55240 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x25240)
#14 0x00007ff7caaa84e4 (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x784e4)
#15 0x00007ff7caaa857c (E:\Swift\Toolchains\0.0.0+Asserts\usr\bin\lldb-dap.exe+0x7857c)
#16 0x00007ffb5d4a8740 (C:\WINDOWS\System32\KERNEL32.DLL+0x8740)
#17 0x00007ffb600d0eb4 (C:\WINDOWS\SYSTEM32\ntdll.dll+0xd0eb4)

lldb command-line debugging is mostly working fine, so it looks this is an issue in the toolchain's lldb-dap debug adapter, not some general problem with my debugger setup.

Sorry, I know this is very thin information, unfortunately I haven't found more clues on how to reproduce or narrow this down.

Environment:

• Windows 11 arm64 (running in VMware on an M4 MBP)
• VS Code with swiftlang.swift-vscode Version 2.0.2
• current TBC Swift toolchain

The app's Package.swift

// swift-tools-version: 6.2

import PackageDescription

let GUILinkerSettings: [LinkerSetting] = [
    .unsafeFlags(["-Xlinker", "/SUBSYSTEM:WINDOWS"], .when(configuration: .release)),
    // Update the entry point to point to the generated swift function, this lets us keep the same main method
    // for debug/release
    .unsafeFlags(["-Xlinker", "/ENTRY:mainCRTStartup"], .when(configuration: .release)),
]

let package = Package(
    name: "Compositor-Windows",
    products: [
        .executable(
            name: "Compositor",
            targets: ["Compositor"]),
    ],
    dependencies: [
        // .package(url: "https://github.com/ktraunmueller/swift-cwinrt", branch: "main"),
        // .package(url: "https://github.com/ktraunmueller/swift-uwp", branch: "main"),
        // .package(url: "https://github.com/ktraunmueller/swift-windowsfoundation", branch: "main"),
        // .package(url: "https://github.com/ktraunmueller/swift-windowsappsdk", branch: "main"),
        // .package(url: "https://github.com/ktraunmueller/swift-winui", branch: "main"),
        // .package(url: "https://github.com/ktraunmueller/swift-plugins", branch: "main")
        .package(path: "../../../winrt/swift-cwinrt"),
        .package(path: "../../../winrt/swift-uwp"),
        .package(path: "../../../winrt/swift-win2d"),
        .package(path: "../../../winrt/swift-windowsappsdk"),
        .package(path: "../../../winrt/swift-windowsfoundation"),
        .package(path: "../../../winrt/swift-winui"),
        .package(path: "../Core")
    ],
    targets: [
        .executableTarget(
            name: "Compositor",
            dependencies: [
                .product(name: "CompositorCore", package: "Core"),
                .product(name: "CWinRT", package: "swift-cwinrt"),
                .product(name: "UWP", package: "swift-uwp"),
                .product(name: "Win2D", package: "swift-win2d"),
                .product(name: "WinAppSDK", package: "swift-windowsappsdk"),
                .product(name: "WindowsFoundation", package: "swift-windowsfoundation"),
                .product(name: "WinUI", package: "swift-winui"),
            ],
            swiftSettings: [.interoperabilityMode(.Cxx)],
            linkerSettings: GUILinkerSettings
        ),
    ],
    swiftLanguageModes: [.v5]
)

[ktraunmueller]

Some more information:

I tested the scenario on an x64 machine (same Swift toolchain version), and it was exactly the same crash as on arm64.

I also tested with the CodeLLDB debug adapter for VS Code instead of the lldp-dap debug adapter, and got some Python error:

Launching adapter
liblldb: C:\Swift\Toolchains\0.0.0+Asserts\usr\bin\liblldb.dll
environment: {}
settings: {
  evaluateForHovers: true,
  commandCompletions: true,
  sourceLanguages: [ 'swift' ]
}
[ERROR codelldb] Initialize Python interpreter: Error:  Fail
    Error Message:
    error: module importing failed: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "c:\Users/karl/.vscode/extensions/vadimcn.vscode-lldb-1.11.4/adapter/scripts\codelldb\__init__.py", line 1, in <module>
        from .api import evaluate, wrap, unwrap, get_config, create_webview, display_html, debugger_message
      File "c:\Users/karl/.vscode/extensions/vadimcn.vscode-lldb-1.11.4/adapter/scripts\codelldb\api.py", line 6, in <module>
        from . import interface
      File "c:\Users/karl/.vscode/extensions/vadimcn.vscode-lldb-1.11.4/adapter/scripts\codelldb\interface.py", line 326, in <module>
        current_exec_context: lldb.SBExecutionContext | None = None
    TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

I am also pasting a screenshot here, because the python output is somehow garbled (wide char / 8 bit char?):

I'm using Python 3.9.13 64 bit, by the way.

[ktraunmueller]

I was searching for code in LLVM that calls the assertion-throwing convertUTF16ToUTF8String() function in ConvertUTFWrapper.cpp

Assertion failed: Out.empty(), file D:\r\_work\swift-build\swift-build\SourceCache\llvm-project\llvm\lib\Support\ConvertUTFWrapper.cpp, line 85

and found this candidate, where m_name may be the std::string that is expected to be empty (but is not) when convertUTF16ToUTF8String() is called:

llvm::convertUTF16ToUTF8String(
        llvm::ArrayRef(reinterpret_cast<char *>(pszThreadName),
                       wcslen(pszThreadName) * sizeof(wchar_t)),
        m_name);

Maybe a simple

m_name = "";

before the call to convertUTF16ToUTF8String() would fix the problem.

@compnerd Is there a chance you could sneak that one line into a TBC Swift toolchain build, to see if that gets rid of the failing assertion? I am only asking because I think trying to build the entire Swift toolchain myself is probably futile, and I've really hit a wall with this problem.

[ktraunmueller]

I created llvm#133904

[compnerd]

@compnerd Is there a chance you could sneak that one line into a TBC Swift toolchain build, to see if that gets rid of the failing assertion?

I would like to see a symbolicated stack trace. The assert indicates that the caller is violating a precondition. Just silencing the issue isn't the right thing. If you need to debug urgently and cannot debug the DAP, then debugging via the CLI interface (lldb) should allow you to make progress.