Swift interpreter fails, and compiler also fails


I downloaded swift package for Windows 10 and also Visual Studio 2019 community. Then, installed them with the following components for Visual Studio:

+MSVC v142 - VS 2019 C++ x64/x86 build tools
+Windows Universal CRT (C Runtime)
+Windows 10 SDK

With using the x64 Native Tools for VS2019 Command Prompt in Administrator mode, I copied the several files according to the install help.

copy %SDKROOT%\usr\share\ucrt.modulemap "%UniversalCRTSdkDir%\Include%UCRTVersion%\ucrt\module.modulemap"
copy %SDKROOT%\usr\share\visualc.modulemap "%VCToolsInstallDir%\include\module.modulemap"
copy %SDKROOT%\usr\share\visualc.apinotes "%VCToolsInstallDir%\include\visualc.apinotes"
copy %SDKROOT%\usr\share\winsdk.modulemap "%UniversalCRTSdkDir%\Include%UCRTVersion%\um\module.modulemap"

I also installed Python 3.8.6 on C:\Program Files\Python38.

I kicked off the swift interpreter with --version option as follows:

PS C:\Users\minoh> swift --version
compnerd.org Swift version 5.3 (swift-5.3-RELEASE)
Target: x86_64-unknown-windows-msvc

I kicked off the swift interpreter, however, it failed as follows:

PS C:\Users\minoh> swift

Expected must be checked before access or destruction.
Unchecked Expected contained error:
TypeSystem for language swift doesn't existStack dump:
0. Program arguments: C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe --repl=-disable-objc-interop -sdk "C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk" -color-diagnostics -autolink-library oldnames -autolink-library msvcrt -Xcc -D_MT -Xcc -D_DLL

Crash reproducer for lldb version 10.0.0 (https://github.com/apple/llvm-project revision c39a810ec308dd4a8d93c5011fb73a5c987e8680)
compnerd.org Swift version 5.3 (swift-5.3-RELEASE)

Reproducer written to 'C:\Users\minoh\AppData\Local\Temp\reproducer-9eb792'

Before attaching the reproducer to a bug report:

  • Look at the directory to ensure you're willing to share its content.
  • Make sure the reproducer works by replaying the reproducer.

Replay the reproducer with the following command:
C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe -replay C:\Users\minoh\AppData\Local\Temp\reproducer-9eb792

#0 0x00007ff67d6ccad5 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x1cad5)
#1 0x00007ffab6c8cb7d (C:\WINDOWS\System32\ucrtbase.dll+0x6cb7d)
#2 0x00007ffab6c8db81 (C:\WINDOWS\System32\ucrtbase.dll+0x6db81)
#3 0x00007ffa362e68e1 lldb::SBFile::Write(unsigned char const *, unsigned __int64, unsigned __int64 *) (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x1368e1)
#4 0x00007ffa36732130 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x582130)
#5 0x00007ffa36738242 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x588242)
#6 0x00007ffa36739ce5 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x589ce5)
#7 0x00007ffa36761ed7 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x5b1ed7)
#8 0x00007ffa36763523 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x5b3523)
#9 0x00007ffa36788dd3 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x5d8dd3)
#10 0x00007ffa368b9a73 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x709a73)
#11 0x00007ffa368b8f22 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x708f22)
#12 0x00007ffa366a219d PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f219d)
#13 0x00007ffa3661ea5c PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x46ea5c)
#14 0x00007ffa362c3dac lldb::SBDebugger::RunREPL(enum lldb::LanguageType, char const *) (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x113dac)
#15 0x00007ff67d6b532e (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x532e)
#16 0x00007ff67d6b7e91 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x7e91)
#17 0x00007ff67d6e2060 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x32060)
#18 0x00007ffab9417bd4 (C:\WINDOWS\System32\KERNEL32.DLL+0x17bd4)
#19 0x00007ffab9acce51 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x6ce51)

I also wrote a swift programming file named "test.swift", and kicked off the compiler as follows:

PS C:\Users\minoh> swiftc test.swift

clang: error: no such file or directory: 'C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\lib\swift\windows\x86_64\swiftrt.obj'
:0: error: link command failed with exit code 1 (use -v to see invocation)

It was true, because there was no file named "swiftrt.obj" on that directory.

I did setup in the x64 Native Tools for VS2019 Command Prompt as follows, according to the get started help:

set SWIFTFLAGS=-sdk %SDKROOT% -I %SDKROOT%/usr/lib/swift -L SDKROOT%/usr/lib/swift/windows

and kicked off repl as follows:

swift repl -target x86_64-unknown-windows-msvc %SWIFTFLAGS%

The similar crashed report was displayed, that was displayed when kicking off the interpreter.

Huh, what I should do in the next step?


The REPL failing to start is a known issue with the 5.3 release. A missed patch prevents the REPL from setting up the correct target triple, which results in failing to load the standard library. The development snapshots should allow the REPL to startup.

The best approach would be to use compiled mode instead of the immediate mode. If you are interested in the immediate mode, all the pieces for that in place, though, it is in need of polish. Patches to improve the immediate mode execution would definitely be welcome.

Thank you for your kind answer. I will check the development snapshot in my environment. I mainly use the immediate (REPL) mode in my university class on swift programming when using swift.

1 Like

Finally, by installing the development snapshot with replacing the stable version, swift repl works without any crash. Thank you for your suggestion.

1 Like

Hi @minohara, may I ask which development snapshot version you're using? I'm using the version associated with build 20201012.1 and when I attempt to use the REPL, I get the following error:

Welcome to compnerd.org Swift version 5.3-dev (LLVM 9f1d8f2d933d348, Swift 53bdffd120c41fa).
Type :help for assistance.
1> "hi"
Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Target\SwiftLanguageRuntime.cpp, line 301
 #0 0x00007ff7b720d4a5 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x1d4a5)
 #1 0x00007fff5dc71891 (C:\WINDOWS\System32\ucrtbase.dll+0x71891)
 #2 0x00007fff5dc72861 (C:\WINDOWS\System32\ucrtbase.dll+0x72861)
 #3 0x00007fff5dc7427e (C:\WINDOWS\System32\ucrtbase.dll+0x7427e)
 #4 0x00007fff5dc74175 (C:\WINDOWS\System32\ucrtbase.dll+0x74175)
 #5 0x00007fff5dc74501 (C:\WINDOWS\System32\ucrtbase.dll+0x74501)
 #6 0x00007ffefb6b1d2c PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x671d2c)
 #7 0x00007ffefff73394 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f33394)
 #8 0x00007ffefff78260 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f38260)
 #9 0x00007ffefff75db6 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f35db6)
#10 0x00007ffefff70c89 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f30c89)
#11 0x00007ffefb55ea17 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x51ea17)
#12 0x00007ffefb56ce27 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x52ce27)
#13 0x00007ffefb53956c PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f956c)
#14 0x00007ffefb4e98d9 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4a98d9)
#15 0x00007ffefb4e850e PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4a850e)
#16 0x00007fff5dc214c2 (C:\WINDOWS\System32\ucrtbase.dll+0x214c2)
#17 0x00007fff5f996fd4 (C:\WINDOWS\System32\KERNEL32.DLL+0x16fd4)
#18 0x00007fff603bcec1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x4cec1)

Any advice would be appreciated! Note that I did set up the flags as described in the installation instructions regarding the REPL. Other environment info: Python 3.7.8, Windows 10 build 18362.1082, Build tools version MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.27), Windows SDK 10.0.18362.0.

Sorry, when my last post was written, I just start up the swift repl only. I checked some evaluations on the swift repl, then the similar crash report was displayed... sigh...

It would be better to use the elder components those are specified in the installation page. I will try and report that.

I tried with MSVC - v142 VS 2019 x64/x86 build tools v14.25, Windows 10 SDK (10.0.17763.0). The similar crash report was displayed.

This error message would means the lack of runtime stub which should be located D: drive.

 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>swift repl
Welcome to compnerd.org Swift version 5.3-dev (LLVM 2685951d827b16e, Swift ec72db1d8ab63fa).
Type :help for assistance.
1> 34
Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Target\SwiftLanguageRuntime.cpp, line 300
 #0 0x00007ff7152ed465 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x1d465)
 #1 0x00007ffab6c8cb7d (C:\WINDOWS\System32\ucrtbase.dll+0x6cb7d)
 #2 0x00007ffab6c8db81 (C:\WINDOWS\System32\ucrtbase.dll+0x6db81)
 #3 0x00007ffab6c8f5be (C:\WINDOWS\System32\ucrtbase.dll+0x6f5be)
 #4 0x00007ffab6c8f4b5 (C:\WINDOWS\System32\ucrtbase.dll+0x6f4b5)
 #5 0x00007ffab6c8f841 (C:\WINDOWS\System32\ucrtbase.dll+0x6f841)
 #6 0x00007ffa2ba18a5c PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x678a5c)
 #7 0x00007ffa302b2a74 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f12a74)
 #8 0x00007ffa302b76e6 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f176e6)
 #9 0x00007ffa302b5376 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f15376)
#10 0x00007ffa302b00f7 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f100f7)
#11 0x00007ffa2b8c8d27 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x528d27)
#12 0x00007ffa2b8d6d72 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x536d72)
#13 0x00007ffa2b8a382c PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x50382c)
#14 0x00007ffa2b853b89 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4b3b89)
#15 0x00007ffa2b8527be PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4b27be)
#16 0x00007ffab6c40e82 (C:\WINDOWS\System32\ucrtbase.dll+0x20e82)
#17 0x00007ffab9417bd4 (C:\WINDOWS\System32\KERNEL32.DLL+0x17bd4)
#18 0x00007ffab9acce51 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x6ce51)

Finally, I will try "Swift for Windows" according to the following video. If it will success, I introduce that software in my class until this bug is fixed.

That’s something that I’ve not encountered before. I wonder what’s different or if there’s been a recent regression. I don’t run the immediate mode very often, and there is a ton to do outside of that, so help to improve the immediate mode is welcome.

BTW, the output of lldb -x -S lldb.init --repl="-sdk %SDKROOT%" where lldb.init contains:

log enable lldb expr
log enable lldb types

Would be helpful.

Sorry for the delayed response, @compnerd. I got around to capturing the output you asked for. It was quite long (~4000 lines of console output) so I threw it into a gist. Here's a link: https://gist.github.com/klcantrell/4b8769219b80ef01b4a8eac113937a23. Hope that helps, please let me know if you could use any other info.

Interesting - seems that loading swiftCore.dll is failing? However, that should be mapped in by the repl process itself: https://github.com/apple/llvm-project/blob/swift/main/lldb/tools/repl/swift/main.c#L64-L66

Would you be able to launch the repl without the init script, and after it loads provide the output of :image list ? The library should be mapped in from the entry point.

I wonder if @JDevlieghere has any idea of why LLDB would be failing to find the library mapping.

Thanks for looking into it. Here's what I get from :image list:

Welcome to compnerd.org Swift version 5.3-dev (LLVM 9f1d8f2d933d348, Swift 53bdffd120c41fa).
Type :help for assistance.
1> :image list
[  0]                                      0x00007ff776060000 C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\repl_swift.exe
[  1] 01DEFFF8-45AA-A742-EA34-488610D487CB-00000001 0x00007ffca8d10000 C:\Windows\System32\ntdll.dll
[  2] 89C3B9FD-1C79-6A0F-430E-0CEF0646F003-00000001 0x00007ffca7150000 C:\Windows\System32\kernel32.dll
[  3] C1F1DEA0-6E06-02EB-C5B8-48F55576F84A-00000001 0x00007ffca6870000 C:\Windows\System32\KernelBase.dll
[  4] EE98F084-3F40-858D-C51E-8E564ADED5DF-00000001 0x00007ffca6bc0000 C:\Windows\System32\ucrtbase.dll
[  5] D2796235-9F13-40C9-87E3-28F9230B21DB-00000001 0x00007ffc92960000 C:\Windows\System32\vcruntime140.dll

The indentation for line [ 0] seemed odd, but I ran it multiple times and it was output that way each time.

I suspect that someone didn't update the padding when the suffix was added to the image GUID, which explains the indentation - but that's not really a correctness issue, just an annoyance.

Interesting, seems that the LoadLibary in the REPL has failed itself. I wonder what is going on there - seems like this might need some actual changes to figure out why the LoadLibrary is failing.

1 Like

If there's anything else you'd like me to try, let me know @compnerd. I've never pulled down any of the Swift projects for development purposes, but I'm willing to learn/try stuff if you had something in mind to test with my environment.

Help is absolutely welcome! I would say that a good first step would be getting a build going.

The problem in this case is going to be in the module loading in lldb. It might be something to do with the process creation (Path not being setup properly perhaps?) or something else going wrong in loading modules. This definitely feels like something has changed, as this used to work pretty well.

A workaround would be copying the swift runtime into the same directory as the toolchain, but that is a less than ideal solution - you either lose the ability to easily and cleanly distribute the runtime, or you end up with duplication which can diverge.

Terms of Service

Privacy Policy

Cookie Policy