I am working on my Apple Watch app. Most of my components use JSON and use the Swift Codable protocol to decode JSON.
Now I wanted to prepare my release, but I received a message by a Beta tester that the App was always crashing on his Series 3.
After I installed the TestFlight build on my Series 3 I could reproduce the issue.
The crash logs from TestFlight and the crash logs extracted from my iPhone indicate that the crash is happening while the JSON gets decoded.
I have rather complex JSON structures, but I did not do any changes to them since the last update. Furthermore, decoding JSON works fine on Xcode builds (also on Series 3) and on newer Apple Watches (Series 4 + 5). I am struggling to find out what could cause the issue.
I discovered a post in the Apple developer forums with a similar issue, but without a solution to it: https://forums.developer.apple.com/thread/124627
Here's a part of the Stacktrace of my crash log:
Date/Time: 2020-02-05 08:37:42.9924 +0100
Launch Time: 2020-02-05 08:37:40.0000 +0100
OS Version: Watch OS 6.1.2 (17S5792a)
Release Type: User
Baseband Version: 4.40.02
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Application Specific Information:
abort() called
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x4d9aefc8 __pthread_kill + 8
1 libsystem_pthread.dylib 0x4da260be pthread_kill + 108
2 libsystem_c.dylib 0x4d9383a4 abort + 84
3 libswiftCore.dylib 0x6cffbade swift_vasprintf+ 2341598 (char**, char const*, char*) + 0
4 libswiftCore.dylib 0x6d00932c swift::TargetMetadata<swift::InProcess>::getGenericArgs+ 2396972 () const + 0
5 libswiftCore.dylib 0x6d00508c _swift_initClassMetadataImpl+ 2379916 (swift::TargetClassMetadata<swift::InProcess>*, swift::ClassLayoutFlags, unsigned long, swift::TypeLayout const* const*, unsigned long*, bool) + 28
6 libswiftCore.dylib 0x6d005c86 swift_initClassMetadata2 + 22
7 libswiftCore.dylib 0x6cfdc6fc type metadata completion function for _KeyedDecodingContainerBox + 50
8 libswiftCore.dylib 0x6d00a6c2 swift::MetadataCacheEntryBase<(anonymous namespace)::GenericCacheEntry, void const*>::doInitialization+ 2401986 (swift::ConcurrencyControl&, swift::MetadataCompletionQueueEntry*, swift::MetadataRequest) + 178
9 libswiftCore.dylib 0x6d003a0c swift_getGenericMetadata + 1124
10 libswiftCore.dylib 0x6cdf4210 KeyedDecodingContainer.init<A>+ 213520 (_:) + 40
11 libswiftFoundation.dylib 0x6d156e0a __JSONDecoder.container<A>+ 323082 (keyedBy:) + 678
12 libswiftFoundation.dylib 0x6d1a3a1c protocol witness for Decoder.container<A>+ 637468 (keyedBy:) in conformance __JSONDecoder + 18
13 libswiftFoundation.dylib 0x6d1592b6 protocol witness for Decoder.container<A>+ 332470 (keyedBy:) in conformance __JSONDecoder + 32
14 libswiftCore.dylib 0x6cfdb1cc dispatch thunk of Decoder.container<A>+ 2208204 (keyedBy:) + 24
15 WatchSonos WatchKit Extension 0x00440bf2 0x358000 + 953330
16 WatchSonos WatchKit Extension 0x0043d08c 0x358000 + 938124
17 libswiftCore.dylib 0x6cfdb156 dispatch thunk of Decodable.init+ 2208086 (from:) + 12
18 libswiftFoundation.dylib 0x6d16fbee __JSONDecoder.unbox_+ 424942 (_:as:) + 4014
19 libswiftFoundation.dylib 0x6d156816 JSONDecoder.decode<A>+ 321558 (_:from:) + 642
20 libswiftFoundation.dylib 0x6d22af98 dispatch thunk of JSONDecoder.decode<A>+ 1191832 (_:from:) + 28
21 WatchSonos WatchKit Extension 0x0045db0c 0x358000 + 1071884
22 WatchSonos WatchKit Extension 0x00461cce 0x358000 + 1088718
23 WatchSonos WatchKit Extension 0x00461bde 0x358000 + 1088478
24 WatchSonos WatchKit Extension 0x00420ffa 0x358000 + 823290
25 WatchSonos WatchKit Extension 0x00425914 0x358000 + 842004
26 libdispatch.dylib 0x4d851846 _dispatch_call_block_and_release + 10
27 libdispatch.dylib 0x4d8528b8 _dispatch_client_callout + 6
28 libdispatch.dylib 0x4d85c6b0 _dispatch_main_queue_callback_4CF + 868
29 CoreFoundation 0x4dcdbbaa __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 10
30 CoreFoundation 0x4dcd7c00 __CFRunLoopRun + 1832
31 CoreFoundation 0x4dcd723a CFRunLoopRunSpecific + 370
32 GraphicsServices 0x50aebcd0 GSEventRunModal + 96
33 UIKitCore 0x65c91580 UIApplicationMain + 1730
34 libxpc.dylib 0x4da73c80 _xpc_objc_main.cold.3 + 152
35 libxpc.dylib 0x4da649b0 _xpc_objc_main + 184
36 libxpc.dylib 0x4da668c4 xpc_main + 110
37 Foundation 0x4e56b0c6 +[NSXPCListener serviceListener] + 0
38 PlugInKit 0x556d726c 0x556c5000 + 74348
39 WatchKit 0x5cfe9afe WKExtensionMain + 62
40 WatchKit 0x5d09f020 main + 10
Here's the position in the code that crashes:
required public init(from decoder: Decoder) throws {
let values = try decoder.container(keyedBy: CodingKeys.self)
self.id = try values.decode(String.self, forKey: .id)
do {
if values.contains(.groups) {
let groups = try values.decode(Dictionary<String, SonosGroup>.self, forKey: .groups)
self.groups = groups
}
if values.contains(.players) {
let players = try values.decode(Array<SonosPlayer>.self, forKey: .players)
self.players = players
}
}catch let error {
print("Error decoding groups \(error)")
}
}
For me this looks like an Apple bug and I filed feedback for it, but this is no solution for the next release.
Does anyone know what's the difference between a TestFlight build and an Xcode release build?
I tried setting a different optimization level, disabling bitcode (not allowed for Apple Watch Apps) and I started replacing Codable with the good old JSONSerialization.
If anyone knows more about it, thank you for that.
Kind regards
Alex
I was having a very similar problem with Encodable and Decodable's in a swift package. Setting DEAD_CODE_STRIPPING = NO in my apps target fixed it. This seems to be a weird leftover of this bug:
https://bugs.swift.org/browse/SR-11564?focusedCommentId=51285&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-51285
Related
I have been trying to debug this issue for almost 8 days now. Tried everything I can find on the internet / stack overflow / github and still on the same problem. I have done all the basic troubleshooting (cleaning, deintegrating pods, etc.) and even adding the GoogleService-info.plist through Xcode.
There is no problem on debug modes and on android release mode. It only occurs on iOS release mode on test flight and on app store connect but works on the emulator / debug mode. Below is the stack trace:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Application Specific Information:
abort() called
Last Exception Backtrace:
0 CoreFoundation 0x1c8b25e88 __exceptionPreprocess + 164
1 libobjc.A.dylib 0x1c1e538d8 objc_exception_throw + 60
2 FirebaseFirestore 0x102f1bc08 firebase::firestore::util::ObjcThrowHandler(firebase::firestore::util::ExceptionType, char const*, char const*, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 112
3 FirebaseFirestore 0x102f1b78c firebase::firestore::util::Throw(firebase::firestore::util::ExceptionType, char const*, char const*, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 20
4 FirebaseFirestore 0x102f2284c void firebase::firestore::util::ThrowInvalidArgument<>(char const*) + 56
5 FirebaseFirestore 0x102f4d3b4 -[FIRFirestore documentWithPath:] + 308
6 Runner 0x1023730c4 -[FLTFirebaseFirestoreReader readValueOfType:] + 2339012 (FLTFirebaseFirestoreReader.m:38)
7 Flutter 0x10576d9c0 0x1051f4000 + 5740992
8 Runner 0x102373040 -[FLTFirebaseFirestoreReader readValueOfType:] + 2338880 (FLTFirebaseFirestoreReader.m:79)
9 Flutter 0x10576ee54 0x1051f4000 + 5746260
10 Flutter 0x10576bc8c 0x1051f4000 + 5733516
11 Flutter 0x105237de4 0x1051f4000 + 277988
12 libdispatch.dylib 0x1d00f44b4 _dispatch_call_block_and_release + 32
13 libdispatch.dylib 0x1d00f5fdc _dispatch_client_callout + 20
14 libdispatch.dylib 0x1d01047f4 _dispatch_main_queue_drain + 928
15 libdispatch.dylib 0x1d0104444 _dispatch_main_queue_callback_4CF + 44
16 CoreFoundation 0x1c8bb66f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
17 CoreFoundation 0x1c8b98058 __CFRunLoopRun + 2036
18 CoreFoundation 0x1c8b9ced4 CFRunLoopRunSpecific + 612
19 GraphicsServices 0x201e9a368 GSEventRunModal + 164
20 UIKitCore 0x1cb07b3d0 -[UIApplication _run] + 888
21 UIKitCore 0x1cb07b034 UIApplicationMain + 340
22 Runner 0x10213dbe0 main + 23520 (AppDelegate.swift:5)
23 dyld 0x1e7204960 start + 2528
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x205720200 __pthread_kill + 8
1 libsystem_pthread.dylib 0x215b821ac pthread_kill + 268
2 libsystem_c.dylib 0x1d01b13e4 __abort + 128
3 libsystem_c.dylib 0x1d0159c98 abort + 192
4 libc++abi.dylib 0x215ac2b8c abort_message + 132
5 libc++abi.dylib 0x215ab2a80 demangling_terminate_handler() + 336
6 libobjc.A.dylib 0x1c1e59d3c _objc_terminate() + 144
7 libc++abi.dylib 0x215ac1f28 std::__terminate(void (*)()) + 20
8 libc++abi.dylib 0x215ac1ec4 std::terminate() + 56
9 libdispatch.dylib 0x1d00f5ff0 _dispatch_client_callout + 40
10 libdispatch.dylib 0x1d01047f4 _dispatch_main_queue_drain + 928
11 libdispatch.dylib 0x1d0104444 _dispatch_main_queue_callback_4CF + 44
12 CoreFoundation 0x1c8bb66f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
13 CoreFoundation 0x1c8b98058 __CFRunLoopRun + 2036
14 CoreFoundation 0x1c8b9ced4 CFRunLoopRunSpecific + 612
15 GraphicsServices 0x201e9a368 GSEventRunModal + 164
16 UIKitCore 0x1cb07b3d0 -[UIApplication _run] + 888
17 UIKitCore 0x1cb07b034 UIApplicationMain + 340
18 Runner 0x10213dbe0 main + 23520 (AppDelegate.swift:5)
19 dyld 0x1e7204960 start + 2528
Below will also be the code that is affected. I tried to pinpoint the problem and when I comment docRef.get() method, it doesn't crash on test flight anymore:
Future<List<dbResults>> results({
required String collectionKey,
required String documentKey,
required int count,
}) async {
FirebaseFirestore firestore = FirebaseFirestore.instance;
DocumentReference docRef =
firestore.collection(collectionKey).doc(documentKey);
List<dbResults> databaseResults = [];
await docRef.get().then((datasnapshot) {
if (datasnapshot.exists) {
try {
datbaseResults = datasnapshot.get('results');
// Additional Logic Here which won't even matter as
// it throws on docRef.get() itself (tried and tested)
}
} catch (_) {
if (kDebugMode) {
print("Error fetching game database results.");
}
}
}
});
return databaseResults;
}
Flutter: 3.3.9
Pubspec:
Cloud Firestore : 4.1.0
Firebase Core: 2.3.0
Any help would be appreciated!
I have exhausted the resources online and submitted +30 builds just to address the issue.
I managed to fix it by adding a conditional check on the parameters being passed to the function if they are not empty before performing the query.
Just a bit weird because the above function isn't even being called on app start and it seems that Swift is trying to call the function on app start and crash but on Android Release and both debug modes, everything is normal.
For all the other devs out there that is on the same boat, please learn from my mistake
Thank you Ali Nabel for helping too!
This question already has answers here:
CLLocationCoordinate2D can't be instantiated
(2 answers)
Closed 1 year ago.
I'm trying to initialize a CLLocationCoordinate2D from a Swift Playground, and I'm getting the error:
error: Execution was interrupted, reason: signal SIGABRT.
The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.
Not sure what I'm doing wrong. Here is what I tried:
var temporaryCoordinate = CLLocationCoordinate2D(latitude: 0.0, longitude: 0.0)
You have found a very unusual and interesting bug. I can reproduce your problem by running the following code in a Blank iOS playground:
import UIKit
import CoreLocation
var temporaryCoordinate = CLLocationCoordinate2D(latitude: 0.0, longitude: 0.0)
What is going wrong is that the runtime environment, the Playground, is itself crashing. In the Mac, in the Console app, with Crash Reports left tab, we can see that the Xcode Playground is crashing.
Process: scratch-playground [1696]
Path: /Users/USER/Library/Developer/XCPGDevices/D22341D9-BFF3-4575-9801-1405F0AA2EA2/data/Containers/Bundle/Application/67A50F6D-18E8-4220-A2EB-8673018601AA/scratch-playground-1381-1.app/scratch-playground
Identifier: scratch-playground
Version: 1.0 (1)
Code Type: ARM-64 (Native)
Parent Process: ??? [1697]
Responsible: SimulatorTrampoline [635]
User ID: 501
Date/Time: 2021-04-06 21:43:05.608 +0100
OS Version: macOS 11.2.3 (20D91)
Report Version: 12
Anonymous UUID: BFEAE183-A757-B843-D9D2-BF254A4665C2
Time Awake Since Boot: 6300 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
External Modification Warnings:
Debugger attached to process.
Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSValue valueWithMKCoordinate:]: unrecognized selector sent to class 0x1c9d3f588'
terminating with uncaught exception of type NSException
abort() called
CoreSimulator 732.18.6 - Device: iPad Pro (9.7-inch) (D22341D9-BFF3-4575-9801-1405F0AA2EA2) - Runtime: iOS 14.4 (18D46) - DeviceType: iPad Pro (9.7-inch)
Application Specific Backtrace 1:
0 CoreFoundation 0x00000001803f61fc __exceptionPreprocess + 236
1 libobjc.A.dylib 0x000000018016a438 objc_exception_throw + 56
2 CoreFoundation 0x00000001804053bc __CFExceptionProem + 0
3 CoreFoundation 0x00000001803fa45c ___forwarding___ + 1408
4 CoreFoundation 0x00000001803fc42c _CF_forwarding_prep_0 + 92
5 libswiftCoreLocation.dylib 0x00000001b1f98044 $s12CoreLocation39CLLocationCoordinate2DInNSValueObjCType33_25AD2332B1DC67E23B54508C4A7DAD45LLSPys4Int8VGvpfiAFyXEfU_ + 104
6 libswiftCoreLocation.dylib 0x00000001b1f97fcc globalinit_33_25AD2332B1DC67E23B54508C4A7DAD45_func0 + 12
7 libdispatch.dylib 0x0000000180100c48 _dispatch_client_callout + 16
8 libdispatch.dylib 0x0000000180102300 _dispatch_once_callout + 28
9 libswiftCore.dylib 0x000000018eed4ee8 swift_once + 44
10 libswiftCoreLocation.dylib 0x00000001b1f9817c $sSo22CLLocationCoordinate2DVs21_ObjectiveCBridgeable12CoreLocationsACP09_bridgeToC1C01_C5CTypeQzyFTW + 116
11 libswiftCore.dylib 0x000000018eeac510 _ZL37bridgeAnythingNonVerbatimToObjectiveCPN5swift11OpaqueValueEPKNS_14TargetMetadataINS_9InProcessEEEb + 360
12 libswiftCore.dylib 0x000000018ec10d70 $ss27_bridgeAnythingToObjectiveCyyXlxlF + 184
13 PlaygroundLogger 0x0000000100c6f9f8 globalinit_33_86996C1BC443F28F24E6A34F24210E4B_func8 + 2132
14 PlaygroundLogger 0x0000000100c6c848 globalinit_33_B1F54B50FE3698781248948D54A93147_func6 + 520
15 PlaygroundLogger 0x0000000100c6db44 playground_log_hidden + 276
16 ??? 0x0000000100c34350 0x0 + 4307764048
17 scratch-playground 0x0000000100ac2ea4 main + 0
18 CoreFoundation 0x0000000180365254 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20
19 CoreFoundation 0x00000001803644ec __CFRunLoopDoBlocks + 404
20 CoreFoundation 0x000000018035eda8 __CFRunLoopRun + 780
21 CoreFoundation 0x000000018035e58c CFRunLoopRunSpecific + 572
22 GraphicsServices 0x000000018b9c2740 GSEventRunModal + 160
23 UIKitCore 0x00000001843ccbf0 -[UIApplication _run] + 964
24 UIKitCore 0x00000001843d19d0 UIApplicationMain + 112
25 scratch-playground 0x0000000100ac2f7c main + 216
26 libdyld.dylib 0x0000000180223cbc start + 4
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00000001bd7c3c10 __pthread_kill + 8
1 libsystem_pthread.dylib 0x00000001bd7fc034 pthread_kill + 260
2 libsystem_c.dylib 0x00000001800f378c abort + 100
3 libc++abi.dylib 0x000000018021cf20 abort_message + 128
4 libc++abi.dylib 0x000000018020ef1c demangling_terminate_handler() + 296
5 libobjc.A.dylib 0x000000018016a6e8 _objc_terminate() + 124
6 libc++abi.dylib 0x000000018021c3c0 std::__terminate(void (*)()) + 16
7 libc++abi.dylib 0x000000018021c358 std::terminate() + 44
8 libdispatch.dylib 0x0000000180100c5c _dispatch_client_callout + 36
9 libdispatch.dylib 0x0000000180102300 _dispatch_once_callout + 28
10 libswiftCore.dylib 0x000000018eed4ee8 swift_once + 44
11 libswiftCoreLocation.dylib 0x00000001b1f9817c protocol witness for _ObjectiveCBridgeable._bridgeToObjectiveC() in conformance CLLocationCoordinate2D + 116
12 libswiftCore.dylib 0x000000018eeac510 bridgeAnythingNonVerbatimToObjectiveC(swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*, bool) + 360
13 libswiftCore.dylib 0x000000018ec10d70 _bridgeAnythingToObjectiveC<A>(_:) + 184
14 com.apple.dt.PlaygroundLogger 0x0000000100c6f9f8 0x100c68000 + 31224
15 com.apple.dt.PlaygroundLogger 0x0000000100c6c848 0x100c68000 + 18504
16 com.apple.dt.PlaygroundLogger 0x0000000100c6db44 playground_log_hidden + 276
17 ??? 0x0000000100c34350 0 + 4307764048
18 com.apple.dt.playground.stub.iOS_Simulator.scratch-playground-10BCB7AC-7E28-4D75-BC98-3FA7A44E2F36 0x0000000100ac2ea4 linkResources + 328
19 com.apple.CoreFoundation 0x0000000180365254 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20
20 com.apple.CoreFoundation 0x00000001803644ec __CFRunLoopDoBlocks + 404
21 com.apple.CoreFoundation 0x000000018035eda8 __CFRunLoopRun + 780
22 com.apple.CoreFoundation 0x000000018035e58c CFRunLoopRunSpecific + 572
23 com.apple.GraphicsServices 0x000000018b9c2740 GSEventRunModal + 160
24 com.apple.UIKitCore 0x00000001843ccbf0 -[UIApplication _run] + 964
25 com.apple.UIKitCore 0x00000001843d19d0 UIApplicationMain + 112
26 com.apple.dt.playground.stub.iOS_Simulator.scratch-playground-10BCB7AC-7E28-4D75-BC98-3FA7A44E2F36 0x0000000100ac2f7c main + 216
27 libdyld.dylib 0x0000000180223cbc start + 4
I think the problem is that there are two Core Location binaries in play:
0x18321e000 - 0x1832a8fff com.apple.corelocation (2420.12.16 - 2420.12.16) <F94D1F57-86D5-3A82-8F2B-80A9AEAC0308> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreLocation.framework/CoreLocation
and
0x1b1f96000 - 0x1b1f98fff +libswiftCoreLocation.dylib (5) <EE615605-C11D-3F60-B611-8B1C1D45FEEA> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswiftCoreLocation.dylib
and the playground is communicating from one world to the other world; talking to the iOS simulator. But there is an incompatibility between the two as the message is not carried across correctly due to type confusion. This leads to the
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSValue
valueWithMKCoordinate:]: unrecognized selector sent to class
0x1c9d3f588' terminating with uncaught exception of type NSException
I think you should file a bug with Apple. To avoid the problem, write your code based on the iOS Simulator directly, instead of using the Playground. In such circumstances, your code will execute correctly (since it directly will run against the simulator without the intervening bridge from the Playground).
As Alexander says in his comment, there is nothing wrong with the code you posted. The cause of the crash is elsewhere.
I've been getting some weird crash logs from my Mac app. Here's the crashed thread:
OS Version: Mac OS X 10.14.6 (18G103)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_MAPERR at 0x0
Crashed Thread: 8
Thread 8 Crashed:
0 ??? 0x0000000000000000 0x0 + 0
1 libswiftCore.dylib 0x00007fff79a743f3 swift_getSingletonMetadata + 578
2 PowerPhotos 0x000000010323f30d type metadata accessor for PowerPhotos.IPAssetCollectionUpdate (<compiler-generated>:0)
3 libswiftCore.dylib 0x00007fff79a8c94c swift::TargetProtocolConformanceDescriptor<swift::InProcess>::getCanonicalTypeMetadata() const + 171
4 libswiftCore.dylib 0x00007fff79a8da24 swift_conformsToSwiftProtocolImpl(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*, llvm::StringRef) + 291
5 libswiftCore.dylib 0x00007fff79a8d884 swift_conformsToProtocolImpl(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*) + 99
6 PowerPhotos 0x000000010339e7a9 swift::swift50override_conformsToProtocol(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*, swift::TargetWitnessTable<swift::InProcess> const* (*)(swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptor<swift::InProcess> const*)) + 56
7 libswiftCore.dylib 0x00007fff79a6215a swift::_conformsToProtocol(swift::OpaqueValue const*, swift::TargetMetadata<swift::InProcess> const*, swift::TargetProtocolDescriptorRef<swift::InProcess>, swift::TargetWitnessTable<swift::InProcess> const**) + 41
8 libswiftCore.dylib 0x00007fff79a65f97 _conformsToProtocols(swift::OpaqueValue const*, swift::TargetMetadata<swift::InProcess> const*, swift::TargetExistentialTypeMetadata<swift::InProcess> const*, swift::TargetWitnessTable<swift::InProcess> const**) + 230
9 libswiftCore.dylib 0x00007fff79a65369 _dynamicCastToExistential(swift::OpaqueValue*, swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*, swift::TargetExistentialTypeMetadata<swift::InProcess> const*, swift::DynamicCastFlags) + 488
10 libswiftCore.dylib 0x00007fff79836517 Swift._print_unlocked<A, B where B: Swift.TextOutputStream>(A, inout B) -> () + 550
11 PowerPhotos 0x00000001031e2483 PowerPhotos.IPArchiveUpdateOperation.(loadFromReplay in _C3BCBD43848FA0F2A85DA8591115A6A7)() -> PowerPhotos.IPArchiveLoadResult (<compiler-generated>:0)
12 PowerPhotos 0x00000001031e1700 PowerPhotos.IPArchiveUpdateOperation.(loadFromPreferredDatabase in _C3BCBD43848FA0F2A85DA8591115A6A7)() -> (PowerPhotos.IPArchiveLoadResult, Swift.Error?) (IPArchiveUpdateOperation.swift:430)
13 PowerPhotos 0x00000001031e08fa PowerPhotos.IPArchiveUpdateOperation.perform() throws -> Any (IPArchiveUpdateOperation.swift:218)
14 PowerPhotos 0x00000001031e179c #objc PowerPhotos.IPArchiveUpdateOperation.perform() throws -> Any (<compiler-generated>:0)
15 BWFoundation 0x00000001036c8173 -[BWOperation main] (BWOperation.m:124)
16 PowerPhotosKit 0x0000000103898e71 -[IPOperation main] (IPOperation.m:287)
17 Foundation 0x00007fff502f5ced -[__NSOperationInternal _start:] + 684
18 Foundation 0x00007fff5031fca7 __NSOQSchedule_f + 226
19 libdispatch.dylib 0x00007fff7a0055f8 _dispatch_call_block_and_release + 11
20 libdispatch.dylib 0x00007fff7a00663d _dispatch_client_callout + 7
21 libdispatch.dylib 0x00007fff7a008de6 _dispatch_continuation_pop + 413
22 libdispatch.dylib 0x00007fff7a0084a3 _dispatch_async_redirect_invoke + 702
23 libdispatch.dylib 0x00007fff7a0143bc _dispatch_root_queue_drain + 323
24 libdispatch.dylib 0x00007fff7a014b46 _dispatch_worker_thread2 + 89
25 libsystem_pthread.dylib 0x00007fff7a2466b3 _pthread_wqthread + 582
26 libsystem_pthread.dylib 0x00007fff7a2463fd start_wqthread + 12
27 ??? 0x0000000054485244 0x0 + 0
Frame 11 is the last time my own code is seen, that line of code looks like this:
return IPArchiveLoadResult(error: NSError(description: "Replay did not complete \(replayDatabase.replayState.debugDescription)"))
So it looks like the call to debugDescription is what's generating the rest of the stack trace, to create that interpolated string. This ultimately ends up in frame 3 which references 'type metadata accessor for PowerPhotos.IPAssetCollectionUpdate'.
But here's the weird thing: IPAssetCollectionUpdate has absolutely nothing to do with the code that's calling this stuff. It's in an entirely different part of the application. So I think it's mostly coincidental that this is triggering whatever metadata loading Swift is doing here.
Looking at IPAssetCollectionUpdate, I think I see what's probably tripping it up:
#available(OSX 10.15, *)
struct IPAssetCollectionUpdate {
let assetCollection: PHAssetCollection
let diff: CollectionDifference<PHAsset>
}
Notice that IPAssetCollectionUpdate is marked as available only on macOS 10.15, and the crashes are all occurring on macOS 10.14. PHAssetCollection and PHAsset do exist on macOS 10.14, but CollectionDifference does not. This isn't a problem in the rest of the app, since everything's protected by the #available directive, but it seems that the Swift runtime is still trying to dig into this struct and generate some internal metadata and blowing up when it can't handle CollectionDifference. Or something like that?
Anyway, that's the setup, so my questions are:
Should this be considered a Swift bug? It seems like with everything properly annotated with availability directives, I should be able to ship this on macOS 10.14 and not have things crash, since I'm never actually using this struct at all on 10.14.
Regardless of whose fault it is, is there any way I can change this code so that it doesn't blow up on 10.14? The best I can think of is to break it out into a loadable bundle in my app and load the bundle manually when running on 10.15. That seems like a lot of work for this silly problem though, and I'd like to know if there's some other simpler way to handle this.
I'm compiling this using Xcode 11.5 and Swift 5.
OK, Stack Overflow was a good rubber duck for me here, I was able to avoid the crash by doing the following:
struct IPAssetCollectionUpdate {
let assetCollection: PHAssetCollection
let typeErasedDiff: Any
var diff: CollectionDifference<PHAsset> {
return self.typeErasedDiff as! CollectionDifference<PHAsset>
}
}
It's terrible, but it works. But my question about whether this should be considered a Swift bug remains, and whether there's a more sanctioned way to write this type of code.
We see a sporadic crash in our user base, during a routine read from NSUserDefaults. The overwhelming majority of users don't experience this problem, and those that do aren't running any particular version of iOS. It seems to have appeared only since we started deploying with Xcode 9.1.
EXC_BAD_ACCESS KERN_PROTECTION_FAILURE 0x000000016efe3fc0
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x101816d4c #objc _NSContiguousString.length() + 5720
1 CoreFoundation 0x181e2a168 CFStringCompareWithOptionsAndLocale + 96
2 Foundation 0x1828602fc -[NSString isEqualToString:] + 76
3 CoreFoundation 0x181e19558 CFEqual + 596
4 CoreFoundation 0x181e15414 CFBasicHashFindBucket + 344
5 CoreFoundation 0x181e152a0 CFDictionaryGetValue + 224
6 CoreFoundation 0x181ef0c74 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 108
7 CoreFoundation 0x181f8f224 -[CFPrefsSource copyValueForKey:] + 64
8 CoreFoundation 0x181f992c0 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 40
9 CoreFoundation 0x181ef44f0 __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:buttConfigurationURL:perform:]_block_invoke + 268
10 CoreFoundation 0x181ef3d0c normalizeQuintuplet + 356
11 CoreFoundation 0x181ef43d8 -[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:buttConfigurationURL:perform:] + 108
12 CoreFoundation 0x181f99258 -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 124
13 CoreFoundation 0x181f9bbbc _CFPreferencesGetAppBooleanValueWithContainer + 136
14 Foundation 0x1828517a8 -[NSUserDefaults(NSUserDefaults) boolForKey:] + 112
15 <our code> 0x100d80750 #objc SettingsPersistence.persistedBool.getter (SettingsPersistence.swift:90)
Here's how we retrieve the value (Swift 3, called via Objective C):
fileprivate static let PersistedBoolKey = "persistedBool"
public var persistedBool: Bool {
get {
return UserDefaults.standard.bool(forKey: SettingsPersistence.PersistedBoolKey)
}
set(newPersistedBool) {
UserDefaults.standard.set(newPersistedBool, forKey: SettingsPersistence.PersistedBoolKey)
}
}
I thought it might be a thread issue, but this occurs on the main thread. Either way, NSUserDefaults is documented as completely thread-safe.
This looks to me like a low-level bug in Apple's libraries. What can I do to fix this problem on my end? Who should I report it to? Has anyone else experienced a similar problem?
Thank you!
This crash has disappeared ever since upgrading Xcode to 9.4.1.
I have a custom keyboard for iOS that uses Firebase for analytics. The Firebase app configuration is done at the initializer with a dispatch_once clause with the token as a global variable.
var token: dispatch_once_t = 0
class KeyboardViewController: UIInputViewController {
// ..
override init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: NSBundle?) {
super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
dispatch_once(&token) {
FIRApp.configure()
} // line 90
}
// ..
}
This is working fine but I am receiving many crash reports that indicate crashes on many devices when the app is configured. I am stuck for days trying to figure out the cause. Here is a part of one of the crash reports stack trace:
Exception Type: EXC_CRASH (SIGQUIT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Quit: 3
Termination Reason: Namespace SIGNAL, Code 0x3
Terminating Process: launchd [1]
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x000000018fab6338 __semwait_signal_nocancel + 8
1 libsystem_c.dylib 0x000000018f9e20dc nanosleep$NOCANCEL + 200 (nanosleep.c:104)
2 libsystem_c.dylib 0x000000018fa0568c sleep$NOCANCEL + 44 (sleep.c:62)
3 libsystem_dnssd.dylib 0x000000018fa6e7d4 ConnectToServer + 832 (dnssd_clientstub.c:607)
4 libsystem_dnssd.dylib 0x000000018fa6ff44 DNSServiceCreateConnection + 76 (dnssd_clientstub.c:1785)
5 libsystem_network.dylib 0x000000018fb2d318 __nw_resolver_set_update_handler_block_invoke + 872 (resolver.m:1031)
6 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
7 libdispatch.dylib 0x000000018f97e860 _dispatch_barrier_sync_f_invoke + 84 (queue.c:3457)
8 libsystem_network.dylib 0x000000018fb2ce78 nw_resolver_set_update_handler + 208 (resolver.m:1275)
9 SystemConfiguration 0x0000000190f8a16c __SCNetworkReachabilityRestartResolver + 260 (SCNetworkReachability.c:1711)
10 SystemConfiguration 0x0000000190f891c8 __SCNetworkReachabilitySetDispatchQueue + 764 (SCNetworkReachability.c:1823)
11 SystemConfiguration 0x0000000190f88ccc SCNetworkReachabilityScheduleWithRunLoop + 504 (SCNetworkReachability.c:1586)
12 CustomKeyboard 0x000000010013f630 -[FIRReachabilityChecker start] + 196
13 CustomKeyboard 0x000000010013abac -[FIRNetwork init] + 156
14 CustomKeyboard 0x0000000100132e28 -[FIRClearcutLogger init] + 416
15 CustomKeyboard 0x0000000100132c68 __35+[FIRClearcutLogger sharedInstance]_block_invoke + 36
16 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
17 libdispatch.dylib 0x000000018f971fb4 dispatch_once_f + 56 (once.c:57)
18 CustomKeyboard 0x0000000100132c40 +[FIRClearcutLogger sharedInstance] + 108
19 CustomKeyboard 0x0000000100137214 +[FIRApp initClearcut] + 60
20 CustomKeyboard 0x0000000100136688 +[FIRApp configureDefaultAppWithOptions:sendingNotifications:] + 132
21 CustomKeyboard 0x000000010013643c +[FIRApp configure] + 316
22 libdispatch.dylib 0x000000018f9711c0 _dispatch_client_callout + 16 (object.m:455)
23 libdispatch.dylib 0x000000018f971fb4 dispatch_once_f + 56 (once.c:57)
24 CustomKeyboard 0x00000001000e314c _TFC19CustomKeyboard22KeyboardViewControllercfT7nibNameGSqSS_6bundleGSqCSo8NSBundle__S0_ + 1500 (KeyboardViewController.swift:90)
25 CustomKeyboard 0x00000001000e3270 _TToFC19CustomKeyboard22KeyboardViewControllercfT7nibNameGSqSS_6bundleGSqCSo8NSBundle__S0_ + 112 (KeyboardViewController.swift:0)
26 UIKit 0x00000001971f7688 -[_UIViewServiceViewControllerOperator __createViewController:withContextToken:fbsDisplays:appearanceSerializedRepresentations:legacyAppearance:traitCollection:initialInterfaceOrientation:hostAccessibilityServerPort:canShowTextServices:replyHandler:] + 2216 (UIViewServiceViewControllerOperator.m:1732)
27 CoreFoundation 0x0000000190aee160 __invoking___ + 144
28 CoreFoundation 0x00000001909e1c3c -[NSInvocation invoke] + 284 (NSForwarding.m:2948)
29 CoreFoundation 0x00000001909e66ec -[NSInvocation invokeWithTarget:] + 60 (NSForwarding.m:3019)
Apparently, the call trace after calling FIRApp.configure() is going through system libraries.
One observation from the stack trace is that the crash has something to do with checking the reachability of the device. However, I tried to reproduce a scenario where there is no internet connection but it's working fine.
Please note that all the crashes are happening on iOS 10 and most of them on iPhone 6.
Any help to figure out the cause of the crashes would be appreciated.
It is not recommended to use Firebase Analytics in an extension as the SDK does not support extension well. App extensions have limited functionalities compared to a full app so Firebase Analytics may not work well under some conditions, like the network in this case. The team is looking into supporting extensions better later.
It seems like the network is not available on custom keyboard as stated by Apple
"By default, a keyboard has no network access and cannot share a
container with its containing app. To enable these things, set the
value of the RequestsOpenAccess Boolean key in the Info.plist file to
YES. Doing this expands the keyboard’s sandbox, as described in
Designing for User Trust."
https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html#//apple_ref/doc/uid/TP40014214-CH16-SW1