Simple CLI app which uses async causes segfault on Mac OSX 11

Hi,

I'm not sure if this is intended behaviour but I run into a segfault when running the following code on XCode 13.2.1 on MacOS 11 (works fine on 12)

import Foundation

print("Hello, World!")
func runAsync() async {
  print("async!")
}
Task {
  await runAsync()
}
sleep(5)

Segfault:

#0 0x00007fff2cf09dc7 in swift::ResolveAsSymbolicReference::operator()(swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*) ()

I saw a similar thread related to https://forums.swift.org/t/async-await-crash-on-ios14-with-xcode-13-2-1/54541/12 but using XCode 13.3 beta didn't solve my problem.

Is this supposed to not work? My understanding was that backporting concurrency was now supported by linking to libswift_Concurrency.

I tried optionally linking to this as build step but that didn't help either.

PS I created my project just using the template console app project for mac os in XCode

Answered by DTS Engineer in 706945022

My understanding was that backporting concurrency was now supported by linking to libswift_Concurrency.

Right. But when you build a command-line tool there’s no place to embed a copy of that library. That puts hard limits on the compatibility support that Swift can provide [1].

Notably, if you put your code into an app wrapper (that is, create an app target and replace main.swift with your code) then it’ll actually run:

% sw_vers
ProductName:	macOS
ProductVersion:	11.6
BuildVersion:	20G165
% find Test701969B.app 
Test701969B.app
Test701969B.app/Contents
Test701969B.app/Contents/_CodeSignature
Test701969B.app/Contents/_CodeSignature/CodeResources
Test701969B.app/Contents/MacOS
Test701969B.app/Contents/MacOS/Test701969B
Test701969B.app/Contents/Frameworks
Test701969B.app/Contents/Frameworks/libswift_Concurrency.dylib
Test701969B.app/Contents/Info.plist
Test701969B.app/Contents/PkgInfo
% ./Test701969B.app/Contents/MacOS/Test701969B 
Hello, World!
async!
% 

Depending on your requirements, that may be a sufficient workaround.

Regardless, I recommend that you file a bug about this. IMO this should either work out of the box or Xcode should warn you that it won’t.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Prior to Swift 5 the system would statically link the Swift runtime into each command line tool. That’s no longer supported because it could lead to a situation where you have two copies of the Swift runtime running within a single process.

Accepted Answer

My understanding was that backporting concurrency was now supported by linking to libswift_Concurrency.

Right. But when you build a command-line tool there’s no place to embed a copy of that library. That puts hard limits on the compatibility support that Swift can provide [1].

Notably, if you put your code into an app wrapper (that is, create an app target and replace main.swift with your code) then it’ll actually run:

% sw_vers
ProductName:	macOS
ProductVersion:	11.6
BuildVersion:	20G165
% find Test701969B.app 
Test701969B.app
Test701969B.app/Contents
Test701969B.app/Contents/_CodeSignature
Test701969B.app/Contents/_CodeSignature/CodeResources
Test701969B.app/Contents/MacOS
Test701969B.app/Contents/MacOS/Test701969B
Test701969B.app/Contents/Frameworks
Test701969B.app/Contents/Frameworks/libswift_Concurrency.dylib
Test701969B.app/Contents/Info.plist
Test701969B.app/Contents/PkgInfo
% ./Test701969B.app/Contents/MacOS/Test701969B 
Hello, World!
async!
% 

Depending on your requirements, that may be a sufficient workaround.

Regardless, I recommend that you file a bug about this. IMO this should either work out of the box or Xcode should warn you that it won’t.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Prior to Swift 5 the system would statically link the Swift runtime into each command line tool. That’s no longer supported because it could lead to a situation where you have two copies of the Swift runtime running within a single process.

Thanks Quinn, That clears things up for me. I'll raise a bug in case someone else ends up falling into the same trap

Simple CLI app which uses async causes segfault on Mac OSX 11
 
 
Q