Lldb crashes during VS Code debug session on Windows 10

Using Swift
1

I have just upgraded to Swift 6.1 on Windows 10. I have updated the related VS Code extensions as well. I used the Manual Installation instructions.

For several of my Swift programs, debugging with VS Code is working great, including the newly working (for me) displays of variables (thanks so much for that!).

However in one program, when at a breakpoint, I hit F5 to go. LLDB mysteriously dies in one of a couple ways. The text from the VS Code Debug Console is below.

I plan to submit this to GitHub - swiftlang/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This fork is used to manage Swift’s stable releases of Clang as well as support the Swift project., since the swift project has its own fork. However, the message below in Debug Console #2 says to submit it to the LLVM-project. Does it make sense to submit this to the swift folks?

Also, I thought I'd ask here if anyone has seen this and knows of a work around?

Thanks!

Debug Console #1, for some attempts:

Error while parsing SDK path from debug info: class llvm::Expected __cdecl lldb_private::Platform::GetSDKPathFromDebugInfo(class lldb_private::CompileUnit &) not implemented for 'host' platform.error: Error while parsing SDK path from debug info: class llvm::Expected __cdecl lldb_private::Platform::GetSDKPathFromDebugInfo(class lldb_private::CompileUnit &) not implemented for 'host' platform.

  • 17:29:11.000 ERROR src/socketexternalcom.cpp:47: attach failed!
  • 17:29:20.531 WARNING src/winwatchtowerdriver.cpp:368: Looks like our dir_record disappeared!

Debug Console #2, for most attempts:

Error while parsing SDK path from debug info: class llvm::Expected __cdecl lldb_private::Platform::GetSDKPathFromDebugInfo(class lldb_private::CompileUnit &) not implemented for 'host' platform.error: Error while parsing SDK path from debug info: class llvm::Expected __cdecl lldb_private::Platform::GetSDKPathFromDebugInfo(class lldb_private::CompileUnit &) not implemented for 'host' platform.
Assertion failed: Out.empty(), file C:\Users\swift-ci\jenkins\workspace\swift-6.1-windows-toolchain\llvm-project\llvm\lib\Support\ConvertUTFWrapper.cpp, line 85
PLEASE submit a bug report to GitHub · Where software is built and include the crash backtrace.
Stack dump:
0. Program arguments: "C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe"
Exception Code: 0x80000003
#0 0x00007ff765486565 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x66565)
#1 0x00007ffa92d01881 (C:\WINDOWS\System32\ucrtbase.dll+0x71881)
#2 0x00007ffa92d02851 (C:\WINDOWS\System32\ucrtbase.dll+0x72851)
#3 0x00007ffa92d041b5 (C:\WINDOWS\System32\ucrtbase.dll+0x741b5)
#4 0x00007ffa92d044f1 (C:\WINDOWS\System32\ucrtbase.dll+0x744f1)
#5 0x00007ff9ff1b4590 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\liblldb.dll+0xc84590)
#6 0x00007ff9fef13221 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\liblldb.dll+0x9e3221)
#7 0x00007ff9fe7a2902 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\liblldb.dll+0x272902)
#8 0x00007ff765452fda (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x32fda)
#9 0x00007ff76544285e (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x2285e)
#10 0x00007ff765465b0c (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x45b0c)
#11 0x00007ff765466048 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x46048)
#12 0x00007ff765444c40 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x24c40)
#13 0x00007ff76549ab10 (C:\Program Files\Swift\Toolchains\6.1.0+Asserts\usr\bin\lldb-dap.exe+0x7ab10)
#14 0x00007ffa93fa7374 (C:\WINDOWS\System32\KERNEL32.DLL+0x17374)
#15 0x00007ffa9533cc91 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x4cc91)

2

Without a proper symbolicated stack trace, it is difficult to determine.

The second crash might be the old dap issue? (CC: @z2oh) If so, that has been fixed on main, and we need to backport that change (CC: @mishal_shah).

The first one is unclear ... src/socketexternalcom.cpp is not a LLVM source path AFAIK, so that might be a VSCode failure?

3

The crash in ConvertUTFWrapper.cpp (see also this thread) was fixed in llvm/llvm-project here and cherry-picked to swiftlang/llvm-project here.

I verified and confirmed the fix with TheBrowserCompany's 20250409.2 toolchain build, so any newer build would have that problem fixed, if you can use those toolchain builds.

4

Guys, thanks so much for your help!!

@ktraunmueller, the 20250409.2 toolchain build does indeed fix the debugger-crash issue, very much appreciated that you directed me to that! The debugger is working!!

@compnerd, given your requests to others for followup, I'll assume I need do nothing more for this issue, either here or in github (otherwise let me know and I'd be happy to submit the issue there).

As for the other issues:

  • ERROR src/socketexternalcom.cpp:47: attach failed!
  • Error while parsing SDK path from debug info: class llvm::Expected __cdecl)

I will pursue them separately. They are not show stoppers like this issue was.

Thanks again!!

5

The DAP issue is the same one that was fixed, and the fix back port for 6.1.1 is up.

The other errors require more context (stack traces). It is likely the SDK “error” is benign and just reported due to path sharing (CC: @JDevlieghere, @Adrian_Prantl).

The final error seems VSCode based.

6

@compnerd is correct that the SDK error is not fatal, but it is something that needs to be cleaned up on non-Darwin platforms. On Darwin LLDB reads the SDK "spec" out of DWARF and then uses xcrun to fid a matching SDK. There is no direct equivalent on other platforms, so it might be as simple as just using the the install root of LLDB itself as a default for the 90% case. CC @c_zablit

7

I am curious about the representation for the spec. This might have an equivalent for Windows as we use a similar distribution model for the SDKs there.

8

Cherry-pick to 6.2 in [Cherry-pick into swift/release/6.2] [lldb] Clear thread name container before writing UTF8 bytes (#134150) by adrian-prantl · Pull Request #10790 · swiftlang/llvm-project · GitHub

9

Currently uses these two attributes:

https://lldb.llvm.org/resources/extensions.html#apple-sdk-information

I think the sysroot concept at the very least should be portable to all platforms.

10

DW_AT_APPLE_sdk for now could point to Windows.sdk, Android.sdk, or FreeBSD.sdk on Windows as well. There are some idle musings about possibly building variants for specific SDK versions (e.g. Windows-10.0.17763.0.sdk) in the future, which would make this even more useful.

11

I managed to reproduce this reliably on Windows:

  1. Debug a Swift program with lldb.
  2. Set a breakpoint somewhere.
  3. Run the program.
  4. When the breakpoint hits, type expr 1.

This prints out error: Error while parsing SDK path from debug info: class llvm::Expected<class lldb_private::XcodeSDK> __cdecl lldb_private::Platform::GetSDKPathFromDebugInfo(class lldb_private::CompileUnit &) not implemented for 'host' platform.