I can confirm that our issue is resolved in Xcode 13.3.1.
1 Like
We found that having the work around from this thread in place and jumping from Xcode 13.2.1 to Xcode 13.4 this week broke our app on iOS 14. Remember to remove the work around when you upgrade Xcode :)
3 Likes
We've been seeing concurrency-related crashes in production (ipa archived with Xcode 13.3.1) for a number of iOS 14 users. It has been very difficult to reproduce locally/while attached to the debugger. However, it did just happen to me while running on my iOS 14.8.1 device from Xcode. My output appears a little different from what's been discussed in this thread so I thought I'd share and see if anyone had any insight:
Environment:
macOS 12.4
Version 13.4.1 (13F100)
iPhone SE 1st Gen, iOS 14.8.1
Crash:
Thread 16: EXC_BAD_ACCESS (code=1, address=0x0)
#0 0x00000001a6cf7dbc in swift::ResolveAsSymbolicReference::operator()(swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*) ()
[..]
My output from (lldb) image list does not contain libswift_Concurrency.dylib. Which I suppose explains the crash I'm seeing?
What seems different to what I've seen in this thread,w hen verifying code signature using codesign I get CSSMERR_TP_CERT_REVOKED:
$ codesign -vvv DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/Frameworks/libswift_Concurrency.dylib
DerivedData/MyApp/Build/Products/Development-iphoneos/My App.app/Frameworks/libswift_Concurrency.dylib: CSSMERR_TP_CERT_REVOKED
In architecture: arm64
Output of codesign -r --display returns
$ /usr/bin/codesign -r- --display DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/Frameworks/libswift_Concurrency.dylib
Executable=DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/Frameworks/libswift_Concurrency.dylib
designated => identifier "com.apple.dt.runtime.swiftConcurrency" and anchor apple generic and certificate leaf[subject.CN] = "Apple Development: Created via API (xxx)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */
When verifying code signing of my app's binary, everything seems ok:
$ /usr/bin/codesign -vvv DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/MyApp
DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/MyApp: valid on disk
DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/MyApp: satisfies its Designated Requirement
Potentially interesting, the size of Frameworks/libswift_Concurrency.dylib in my .app is only 513 KB on disk as opposed to the mentioned 1 MB or 11 MB.
Using file I see that it only contains the arm64 architecture slice:
$ file DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/Frameworks/libswift_Concurrency.dylib
DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/Frameworks/libswift_Concurrency.dylib: Mach-O 64-bit dynamically linked shared library arm64
otool -L includes @rpath/libswift_Concurrency.dylib:
$ otool -L DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/MyApp
[..]
@rpath/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 5.6.0, weak)
otool -l output:
otool -l DerivedData/MyApp/Build/Products/Development-iphoneos/MyApp.app/MyApp | grep -A2 RPATH
cmd LC_RPATH
cmdsize 32
path /usr/lib/swift (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/Frameworks (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @loader_path/Frameworks (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/Frameworks (offset 12)
I have found that cleaning DerivedData/ will make this issue go away locally- however, that does not explain the crashes we continue to see for App Store users. It's my understanding that the original issue of this post was address in Xcode 13.3? If so, could any of what I am seeing locally also explain what's happening to users?
I have found that cleaning DerivedData/ will make this issue go away locally- however, that does not explain the crashes we continue to see for App Store users.
do you have any scripts run with regards to linked frameworks or custom linker flags?
have you tried a simple test app and reproduced the issue?
exactly the same scenario happened to me. I refactored code for async/await and running on iPhone 14 .7.1
while running from XCode 13.2.1, it does not crash.
I am using Task {} in applicationDidBecomeActive. I do have a still old version of the code (w/o Async/Await), so if I revert my changes, crashes gone