search

swiftlang / swift

The Swift Programming Language
https://swift.org
Apache License 2.0
67.5k stars 10.35k forks source link

Swift 5.9 (with SWIFT_SWIFT_PARSER on) with -interpret mode, will cause compiler crash on x86_64 Host mac #67933

Open dreampiggy opened 1 year ago

dreampiggy commented 1 year ago

Description

Use Swift 5.9 toolchain (xctoolchain)'s swift binary, to run Swift code in interpret mode (means, using xcrun -toolchain com.foobar swift main.swift, will cause the compiler crash (with stacktrace below). This can not been reproduced on arm64 M1 mac.

The actual compile command is this, in the Xcode's Custom Script build phases:

xcrun --sdk macosx swift /Users/foobar/.gem/ruby/3.0.0/gems/Scaffold-0.1.478/lib/resources/ Sources/main.swift

Some reproducable tip:

  1. Must use the Swift syntax based compiler (means, SWIFT_SWIFT_PARSER=ON when compile Swift compiler itself)
  2. Host mac using x86_64 instead of arm64, OS is macOS 13.4.1
  3. Using -interpret mode, not the normal -c or -emit-executable action

Steps to reproduce

  1. Download main.swift: main.swift.zip
  2. Specify the xctoolchain with Swift 5.9, you can use xcrun -toolchain swift or using TOOLCHAINS environment in Xcode, or directly use swift-5.9.xctoolchain/usr/bin/swift to spawn
  3. See the result

Expected behavior

The compiler should not crash and interpret the Swift code as normal

Environment

Stack trace from stdout:

Could not cast value of type '__NSCFString' (0x7ff84dbcb8a0) to 'Swift.String' (0x1150e1508).
Stack dump:
0.  Program arguments: /Users/foobar/Library/Developer/Toolchains/swift-5.9.xctoolchain/usr/bin/swift-frontend -frontend -interpret /Users/foobar/.gem/ruby/2.6.0/gems/Scaffold-0.1.478/lib/resources/ShortLinkSwift/Sources/main.swift -enable-objc-interop -sdk /Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -external-plugin-path /Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/lib/swift/host/plugins#/Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/local/lib/swift/host/plugins#/Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/swift/host/plugins#/Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/local/lib/swift/host/plugins#/Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server -plugin-path /Users/foobar/Library/Developer/Toolchains/swift-5.9.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Users/foobar/Library/Developer/Toolchains/swift-5.9.xctoolchain/usr/local/lib/swift/host/plugins -target-sdk-version 14.0 -module-name main
1.  Apple Swift version 5.9 (swiftlang-5.9.0.128.2 clang-1500.0.40.1)
2.  Compiling with the current language version
3.  While running user code "/Users/foobar/.gem/ruby/2.6.0/gems/Scaffold-0.1.478/lib/resources/ShortLinkSwift/Sources/main.swift"
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x0000000110b77dc7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
1  swift-frontend           0x0000000110b77205 llvm::sys::RunSignalHandlers() + 85
2  swift-frontend           0x0000000110b78410 SignalHandler(int) + 288
3  libsystem_platform.dylib 0x00007ff80a4865ed _sigtramp + 29
4  libsystem_platform.dylib 000000000000000000 _sigtramp + 18446603370408417840
5  libsystem_c.dylib        0x00007ff80a37fb45 abort + 123
6  libswiftCore.dylib       0x00007ff819d42af4 swift::fatalErrorv(unsigned int, char const*, __va_list_tag*) + 132
7  libswiftCore.dylib       0x00007ff819d42b7b swift::fatalError(unsigned int, char const*, ...) + 123
8  libswiftCore.dylib       0x00007ff819d3a397 swift::swift_dynamicCastFailure(void const*, char const*, void const*, char const*, char const*) + 71
9  libswiftCore.dylib       0x00007ff819d3a40a swift::swift_dynamicCastFailure(swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*, char const*) + 106
10 libswiftCore.dylib       0x00007ff819d3e769 swift_dynamicCast + 249
11 Foundation               0x00007ff80b69306a $sSD10FoundationE26_forceBridgeFromObjectiveC_6resultySo12NSDictionaryC_SDyxq_GSgztFZSiSryxG_Sryq_GtXEfU0_ + 410
12 Foundation               0x00007ff80b695a07 $sSD10FoundationE26_forceBridgeFromObjectiveC_6resultySo12NSDictionaryC_SDyxq_GSgztFZSiSryxG_Sryq_GtXEfU0_TATm + 39
13 Foundation               0x00007ff80b6953d5 $ss17_NativeDictionaryV28_unsafeUninitializedCapacity18allowingDuplicates16initializingWithAByxq_GSi_SbSiSryxG_Sryq_GtXEtcfC + 181
14 Foundation               0x00007ff80b691af4 $sSD10FoundationE36_unconditionallyBridgeFromObjectiveCySDyxq_GSo12NSDictionaryCSgFZ + 452
15 Foundation               0x00000001193779b2 $sSD10FoundationE36_unconditionallyBridgeFromObjectiveCySDyxq_GSo12NSDictionaryCSgFZ + 18446603375107530882
16 Foundation               0x0000000119377d22 $sSD10FoundationE36_unconditionallyBridgeFromObjectiveCySDyxq_GSo12NSDictionaryCSgFZ + 18446603375107531762
17 Foundation               0x000000011937700e $sSD10FoundationE36_unconditionallyBridgeFromObjectiveCySDyxq_GSo12NSDictionaryCSgFZ + 18446603375107528414
18 swift-frontend           0x000000010bceeab3 llvm::orc::runAsMain(int (*)(int, char**), llvm::ArrayRef<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, llvm::Optional<llvm::StringRef>) + 1731
19 swift-frontend           0x000000010bc5fe15 swift::RunImmediately(swift::CompilerInstance&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>> const&, swift::IRGenOptions const&, swift::SILOptions const&, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule>>&&) + 7797
20 swift-frontend           0x000000010bc1dd71 performCompileStepsPostSILGen(swift::CompilerInstance&, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule>>, llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::PrimarySpecificPaths const&, int&, swift::FrontendObserver*) + 2209
21 swift-frontend           0x000000010bc1d35f swift::performCompileStepsPostSema(swift::CompilerInstance&, int&, swift::FrontendObserver*) + 2431
22 swift-frontend           0x000000010bc1ef9f swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 3807
23 swift-frontend           0x000000010ba75179 swift::mainEntry(int, char const**) + 2185
24 dyld                     0x00007ff80a0ff41f start + 1903
/Users/foobar/38380/derived_data/Build/Intermediates.noindex/ArchiveIntermediates/Demo/IntermediateBuildFilesPath/yaml-cpp.build/Release-iphoneos/yaml-cpp.build/Script-380CCE63B7F001A5C14E9C03DBE8C258.sh: line 17:   402 Abort trap: 6           SYSTEM_FRAMEWORK_DIR="${PODS_CONFIGURATION_BUILD_DIR}/yaml-cpp-SystemFrameworks" NORMAL_FRAMEWORK_DIR="${PODS_CONFIGURATION_BUILD_DIR}/yaml-cpp-Frameworks" xcrun --sdk macosx swift /Users/foobar/.gem/ruby/2.6.0/gems/Scaffold-0.1.478/lib/resources/ShortLinkSwift/Sources/main.swift

Personal guess:

  1. The Swift 5.9 toolchain contains it built libswiftCore.dylib, in swift-5.9.xctoolchain/usr/lib/swift/macosx image
  2. And when using SWIFT_SWIFT_PARSER=ON, it try to use LLVM::Orc to JIT the code, and to load the @rpath/libswiftCore.dylib in swift-frontend's MachO load command
  3. However, actually dyld will use shared cache instead of actually load that swift-5.9.xctoolchain/usr/lib/swift/macosx/libswiftCore.dylib image
  4. This cause mismatched behavior, when the Swift compiler itself using interpret or normal compile mode
Kyle-Ye commented 1 year ago
  1. However, actually dyld will use shared cache instead of actually load that swift-5.9.xctoolchain/usr/lib/swift/macosx/libswiftCore.dylib image

It seems that the code you highlight in the screenshot will not be executed on macOS since it was guarded by _WIN32