We've got kind of a weird bug in our app that only one user encounters so far (out of thousands) and I can't figure it out how to solve this, so maybe you can help me further.
It's about the following crash (run-time):
#0. Crashed: com.apple.main-thread
0 libswiftFoundation.dylib 0x10e51ec _TZFV10Foundation4Date36_unconditionallyBridgeFromObjectiveCfGSqCSo6NSDate_S0_ + 68
1 XXX 0x14d804 specialized static Loader._save(NSDictionary, Double, moc : NSManagedObjectContext) -> () (Loader.swift:149)
2 XXX 0x14d804 specialized static Loader._save(NSDictionary, Double, moc : NSManagedObjectContext) -> () (Loader.swift:149)
3 XXX 0x14286c static Loader.(registerUser(NSManagedObjectContext) -> ()).(closure #1) (Loader.swift)
4 Alamofire 0x5aea58 specialized DataRequest.(response<A where ...> (queue : DispatchQueue?, responseSerializer : A, completionHandler : (DataResponse<A.SerializedObject>) -> ()) -> Self).(closure #1).(closure #1) (ResponseSerialization.swift)
5 libdispatch.dylib 0x1b911797 _dispatch_call_block_and_release + 10
6 libdispatch.dylib 0x1b911783 _dispatch_client_callout + 22
7 libdispatch.dylib 0x1b915d05 _dispatch_main_queue_callback_4CF + 902
8 CoreFoundation 0x1c1ffd69 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
9 CoreFoundation 0x1c1fde19 __CFRunLoopRun + 848
10 CoreFoundation 0x1c1510ef CFRunLoopRunSpecific + 470
11 CoreFoundation 0x1c150f11 CFRunLoopRunInMode + 104
12 GraphicsServices 0x1d8fbb41 GSEventRunModal + 80
13 UIKit 0x214d5e83 UIApplicationMain + 150
14 XXX 0xb7b1c main (AppDelegate.swift:26)
15 libdyld.dylib 0x1b93e4eb start + 2
Line 149 of Loader.swift is:
let createDate : Foundation.Date = dateFormatter.date(from: eventCreated)!
It looks like it's an internal problem inside libswiftFoundation.dylib.
I've researched a lot about this problem and the only thing I could find on this was from Apple:
Some Objective-C methods in the SDKs may incorrectly annotate or assume a type to be nonnull rather than nullable. A type that Swift treats as a struct, such as NSURL (Foundation.URL) or NSDate (Foundation.Date), results in a run-time crash in a method with a name like bridgeFromObjectiveC; in other cases, it can lead to crashes or undefined behavior in user code. If you identify such a method, please file a report at bugreport.apple.com. As a workaround, add a trampoline function in Objective-C with the correct nullability annotations. For example, the following function will allow you to call FileManager'senumerator(at:includingPropertiesForKeys:options:errorHandler:) method with an error handler that accepts nil URLs:
https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html (under known issues)
With an example that looks like this:
static inline NSDirectoryEnumerator<NSURL *> * _Nullable
fileManagerEnumeratorAtURL(NSFileManager *fileManager, NSURL * _Nonnull url, NSArray<NSURLResourceKey> * _Nullable keys, NSDirectoryEnumerationOptions options, BOOL (^ _Nullable errorHandler)(NSURL * _Nullable errorURL, NSError * _Nonnull error)) {
return [fileManager enumeratorAtURL:url includingPropertiesForKeys:keys options:options errorHandler:^(NSURL * _Nonnull errorURL, NSError * _Nonnull error) {
return errorHandler(errorURL, error);
}];
}
I've already submitted a bug report for this issue, but still haven't got a response from Apple (after 7 days). I think this could fix the problem, but I'm not sure on how to port the given trampoline function (example) to a valid/working NSDate/DateFormatter version. Does someone know more about this problem and/or got it solved?
Related
I have an intermittent (rarely occurring) crash which, so far has only occurred in the wild with reports from AppStore. With the limited crash log, I have not been able to grok the issue.
I am trying to display an App Store Product page view.
Here is the code
The enclosing class includes the SKStoreProductViewControllerDelegate and
the delegate is set to self.
#objc func adTap(sender: UITapGestureRecognizer? = nil) -> Void {
if adAppID.isEmpty {return}
let paramDict = [SKStoreProductParameterITunesItemIdentifier: adAppID]
storeProductViewController.loadProduct(withParameters: paramDict, completionBlock: { (status: Bool, error: Error?) -> Void in
if status {
self.storeProductViewController.view.frame.origin.y = 0
let eventParams = ["AppID": self.adAppID]
self.present(self.storeProductViewController, animated: true, completion: nil)
}
else {
if let error = error {
print("Error: \(error.localizedDescription)")
}
}})
}
The error is triggered at the self.present:
#8 (null) in thunk for #escaping #callee_guaranteed (#unowned Bool, #guaranteed Error?) -> () ()
#7 0x100b68350 in closure #1 in ViewController.adTap(sender:)
#6 (null) in -[UIViewController presentViewController:animated:completion:] ()
#0 (null) in __exceptionPreprocess ()
Dumping the actual cashpoint file shows a SIGABRT:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x1ad1db278 __exceptionPreprocess + 220 (NSException.m:199)
1 libobjc.A.dylib 0x1acf040a4 objc_exception_throw + 56 (objc-exception.mm:565)
2 UIKitCore 0x1b0bcbe0c -[UIViewController _presentViewController:withAnimationController:completion:] + 4880 (UIViewController.m:7185)
3 UIKitCore 0x1b0bce074 __63-[UIViewController _presentViewController:animated:completion:]_block_invoke + 104 (UIViewController.m:7671)
4 UIKitCore 0x1b0bce570 -[UIViewController _performCoordinatedPresentOrDismiss:animated:] + 508 (UIViewController.m:7772)
5 UIKitCore 0x1b0bcdfc4 -[UIViewController _presentViewController:animated:completion:] + 196 (UIViewController.m:7678)
6 UIKitCore 0x1b0bce22c -[UIViewController presentViewController:animated:completion:] + 160 (UIViewController.m:7716)
7 MyAppName 0x100b68350 closure #1 in ViewController.adTap(sender:) + 1016 (ViewController.swift:991)
8 MyAppName 0x100b68580 thunk for #escaping #callee_guaranteed (#unowned Bool, #guaranteed Error?) -> () + 60 (<compiler-generated>:0)
9 StoreKit 0x1bba3c1e8 -[SKStoreProductViewController _loadDidFinishWithResult:error:] + 48 (SKStoreProductViewController.m:425)
10 StoreKit 0x1bba3e624 -[SKRemoteProductViewController loadDidFinishWithResult:error:] + 128 (SKRemoteProductViewController.m:61)
///////
I understand that the completion block is an implicitly escaping block, but I do not see how it does not fulfill the block spec (arguments, if indeed that is the issue). Again, this is an intermittent event. Never seen it on a device tethered to Xcode or on one of our untethered devices. Recently it has occurred in the field, once on a iPhone 7 running iOS 13, and once on a X running 12.3.1
/////
Any thoughts would be appreciated
Let me write this as answer, as I see now that my comment may be unclear. The block
if status {
self.storeProductViewController.view.frame.origin.y = 0
let eventParams = ["AppID": self.adAppID]
self.present(self.storeProductViewController, animated: true, completion: nil)
}
accesses some UI elements, yet it may not be running on main thread (since it's inside callback). So first thing I would suspect is that it's crashing if it happens to be called outside of main thread. Hence I would try this:
if status {
DispatchQueue.main.async {
self.storeProductViewController.view.frame.origin.y = 0
let eventParams = ["AppID": self.adAppID]
self.present(self.storeProductViewController, animated: true, completion: nil)
}
}
If it helps, maybe think of better MVC separation...
I'm getting a crash, reported in Crashlytics, and I have no idea how to reproduce the error, It happens randomly so it's hard to debug it with Xcode. Any ideas?
Crashed: NSOperationQueue 0x280419200 (QOS: UNSPECIFIED)
0 libobjc.A.dylib 0x22c471430 objc_retain + 16
1 CoreFoundation 0x22d2b5888 __CFBasicHashAddValue + 1480
2 CoreFoundation 0x22d1e64ac CFDictionarySetValue + 260
3 Foundation 0x22dd04888 _encodeObject + 732
4 myAPI 0x1062b44b0 -[DataCore encodeWithCoder:] (DataCore.m:236)
5 myAPI 0x1062909c4 -[DataHandle encodeWithCoder:] (DataHandle.m:53)
6 Foundation 0x22dd04aa8 _encodeObject + 1276
7 Foundation 0x22dc69c6c +[NSKeyedArchiver archivedDataWithRootObject:] + 168
8 myAPI 0x106288a34 __77+[CachableObject addObjectToCache:withCacheName:withTTL:withCompletionBlock:]_block_invoke (CachableObject.m:162)
9 Foundation 0x22dd198bc NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK + 16
10 Foundation 0x22dc21ab8 -[NSBlockOperation main] + 72
11 Foundation 0x22dc20f8c -[__NSOperationInternal _start:] + 740
12 Foundation 0x22dd1b790 __NSOQSchedule_f + 272
13 libdispatch.dylib 0x22ccc16c8 _dispatch_call_block_and_release + 24
14 libdispatch.dylib 0x22ccc2484 _dispatch_client_callout + 16
15 libdispatch.dylib 0x22cc6582c _dispatch_continuation_pop$VARIANT$mp + 412
16 libdispatch.dylib 0x22cc64ef4 _dispatch_async_redirect_invoke + 600
17 libdispatch.dylib 0x22cc71a18 _dispatch_root_queue_drain + 376
18 libdispatch.dylib 0x22cc722c0 _dispatch_worker_thread2 + 128
19 libsystem_pthread.dylib 0x22cea517c _pthread_wqthread + 472
20 libsystem_pthread.dylib 0x22cea7cec start_wqthread + 4
Here is what the code in DataCore.m looks like
- (void)encodeWithCoder:(NSCoder *)coder {
[super encodeWithCoder:coder];
[coder encodeObject:programFormatPlayInfo forKey:#"ProgramFormatPlayInfo"];
[coder encodeObject:bigScreenPlayInfo forKey:#"BigScreenPlayInfo"];
[coder encodeObject:pivotHandle forKey:#"PivotHandle"];
[coder encodeInteger:pivotDataLinkId forKey:#"PivotDataLinkId"];
[coder encodeInteger:viewContextId forKey:#"ViewContextId"];
[coder encodeBool:suppressImagePivot forKey:#"SuppressImagePivot"];
[coder encodeObject:attributeIds forKey:#"AttributeIds"];
[coder encodeObject:self.overflow forKey:#"Overflow"];
[coder encodeObject:self.cacheNameWithUser forKey:#"CacheNameWithUser"];
[coder encodeObject:self.metaData forKey:#"Metadata"];
}
and here is where I try to add an object to the cache,
not sure if it's failing to decode or something related to the background queue.
+ (void)addObjectToCache:(CachableObject*)object withCacheName:(NSString*)cacheName withTTL:(CacheTime)cacheTimeSeconds withCompletionBlock:(void(^)()) block {
CachableObject* theObject = object;
[_backgroundQueue addOperationWithBlock:^{
#autoreleasepool {
#try {
NSString * path = [CachableObject pathForCachedObject:cacheName];
NSDate * date = [NSDate date];
[object setCacheDate:date];
[object setTtlSeconds:[NSNumber numberWithInteger:cacheTimeSeconds]];
[object setApiVersion:APIVERSION];
// Add to NSCache
[[CachableObject objectCache] setObject:theObject forKey:cacheName];
// Add to file system
NSError* err = nil;
NSData * data = [NSKeyedArchiver archivedDataWithRootObject:theObject];
if (data) {
[data writeToFile:path options:NSDataWritingAtomic error:&err];
}
// Add to dynamic cache
unwrapObjectAndComplyWithClass(object, [DataHandle class], ^(id unwrappedObject) {
DataHandle *objectUnwrapped = unwrappedObject;
DataFrame *objectFrame = objectUnwrapped.frame;
for (NSString *eachDependencyName in objectFrame.dependencies) {
[[VVIDynamicCacheManager sharedManager]addDependencyToStore:eachDependencyName withCacheName:cacheName];
}
}, ^{
/*Not a data handle*/
});
} #catch (NSException* ex) {
NSLog(#"CachableObject: got an exception %#", ex);
} #finally {
if (block) {
block();
}
}
}
}];
}
Some thoughts here.
First, you're using #try/#catch. I believe that NSKeyedArchiver throws exceptions when it should actually return NSError objects. So, perhaps that's why you are doing it. But, you have to keep in mind that none of Apple's frameworks are guaranteed to be exception-safe. This means that catching exceptions can leave Apple's code (and, of course, your own) in inconsistent states that will prevent it from working correctly in the future.
I would strongly recommend either removing the #catch, or scoping it extremely tightly around the NSKeyedArchiver code, if that's why you are using it. This could be unintentionally introducing a variety of other bugs into your app.
Now, on to the specific crash. It's occurring in the runtime's memory management code. This points very strongly at heap corruption. This means you've got a pointer that doesn't point to a valid Objective-C object in memory. This can happen for many reasons, and is extremely common. The most common cause is known as a dangling pointer. However, it could also be caused by an over-release. And, I wouldn't be at all surprised if it is possible to use an #catch to trigger an over-release. (I know, I'm harping, but I've seen so many issues caused by this pattern)
What I generally recommend in these situations:
Look for other crashes that look heap-corruption-related
Try out Zombies in Instruments
Try malloc scribble, or guardmalloc, two other good memory debugging tools
It's hard, and often even impossible, to reason about heap corruption. Replicating the bug can also be impossible, as memory corruption is typically not deterministic.
So, just try to find and fix as many issues as you can. It's totally possible that one of them is responsible for a variety of crashes, one of which could be this one.
My iOS app does not use any networking and works fine on my iPhone, but Apple rejected it supposedly due to IPv6 incompatibility issues.
2. 1 PERFORMANCE: APP COMPLETENESS
Performance - 2.1
Your app crashes on iPhone running iOS 10.0.3 connected to an IPv6 network when we:
Specifically, we found your app crashes when we tap “Analyze.”
We have attached detailed crash logs to help troubleshoot this issue.
However when I symbolicated the crash report they sent, it shows a particular thread crashed. The backtrace is below.
Thread 5 name: Dispatch queue: com.apple.HealthKit.HKHealthStore.client.0x1700f6d00
Thread 5 Crashed:
0 libswiftCore.dylib 0x0000000100273ae8 _assertionFailed(StaticString, String, StaticString, UInt, flags : UInt32) -> Never (__hidden#14874_:167)
1 libswiftCore.dylib 0x0000000100273ae8 _assertionFailed(StaticString, String, StaticString, UInt, flags : UInt32) -> Never (__hidden#14874_:167)
2 PickerTest 0x00000001000c1d1c type metadata accessor for String? (PyschicBrain.swift:0)
3 PickerTest 0x00000001000bfe78 PsychicBrain.(isHeartRateInfoAvailableForDates() -> Bool).(closure #1) (PyschicBrain.swift:0)
4 libdispatch.dylib 0x000000018f98d200 _dispatch_call_block_and_release + 24
5 libdispatch.dylib 0x000000018f98d1c0 _dispatch_client_callout + 16
6 libdispatch.dylib 0x000000018f99b444 _dispatch_queue_serial_drain + 928
7 libdispatch.dylib 0x000000018f9909a8 _dispatch_queue_invoke + 652
8 libdispatch.dylib 0x000000018f99b940 _dispatch_queue_override_invoke + 360
9 libdispatch.dylib 0x000000018f99d38c _dispatch_root_queue_drain + 572
10 libdispatch.dylib 0x000000018f99d0ec _dispatch_worker_thread3 + 124
11 libsystem_pthread.dylib 0x000000018fb952c8 _pthread_wqthread + 1288
12 libsystem_pthread.dylib 0x000000018fb94db4 start_wqthread + 4
Stack frame #3 (above) says the closure in the function isHeartRateInfoAvailableForDates() failed, which means the HKSampleQuery failed.
My question: I'm assuming this is because no heart-rate data was found for that interval. On my phone, in this scenario, samples.count() returns 0 and hence the function returns FALSE. When Apple folks test it, obviously they get a different error. I've asked Apple for console logs but I would like to know a more elegant way of error handling.
func isHeartRateInfoAvailableForDates() -> Bool {
predicate = HKQuery.predicateForSamples(withStart: pvtStartDate, end: pvtEndDate, options: HKQueryOptions())
guard let sampleType = HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.heartRate) else {
fatalError("HKSampleType.quantityTypeForIdentifier failed")
}
let dispatchGrp = DispatchGroup()
// Entering query block
//
dispatchGrp.enter()
let query = HKSampleQuery(sampleType: sampleType, predicate: predicate, limit: Int(HKObjectQueryNoLimit), sortDescriptors: nil) {
query, results, error in
guard let samples = results as? [HKQuantitySample] else {
fatalError("An error occured fetching the user's heart rate: \(error?.localizedDescription)");
}
self.pvtSampleCount = samples.count
// leave group once query results are available
dispatchGrp.leave()
}
pvtHealthStore.execute(query)
// Now wait for the query to complete
//
dispatchGrp.wait(timeout: DispatchTime.distantFuture)
return pvtSampleCount > 0
}
I'm having a smartwatch app on watchos2. The app always worked but now when it starts I immediately get this error:
Lop_WatchKit_Extension[17535:7854201] *********** ERROR -[SPRemoteInterface _interfaceControllerClientIDForControllerID:] clientIdentifier for interfaceControllerID:447E0002 not found
I found some topics here on stackoverflow but nothing solved the problem.
In my case, this was due to a retain cycle in one InterfaceController of mine.
If you get the logs similar to:
[default] -[SPRemoteInterface
_interfaceControllerClientIDForControllerID:]:0000: ComF: clientIdentifier for interfaceControllerID:XXXXXXXX not found
&/or...
[default] _SendRecordedValues:000: ComF:<-Plugin controller ID
XXXXXXXX has no client identifier
First, figure out which InterfaceController has the controller ID XXXXXXXX.
Have this in awake(withContext:)
override func awake(withContext context: Any?) {
//...
if let id = self.value(forKey: "_viewControllerID") as? NSString {
let strClassDescription = String(describing: self)
print("\(strClassDescription) has the Interface Controller ID \(id)")
}
//...
}
This logs:
[Target.Classname: 0xYYYYYYYY] has the Interface Controller ID
XXXXXXXX
Once you identify the InterfaceController causing these logs, you can continue to debug.
It could be different in your case but in mine I had created a retain cycle with self in one of my closures within which took awhile to locate but I eventually broke the retain cycle with a [weak self] capture.
Basically, the error logs appear when an InterfaceController is trying to execute some code but it has already been released.
What I already had:
DispatchQueue.main.async {
self.doSomethingThatDoesSomethingAsync()
}
What I fixed:
DispatchQueue.main.async { [weak self] in
self?.doSomethingThatDoesSomethingAsync()
}
If you use didSet on any IBOutlets it will also throw this error in the logs.
class MyInterfaceController: WKInterfaceController {
#IBOutlet var myLabel: WKInterfaceLabel! {
didSet {
myLabel.setTitle("Test")
}
}
How #nickromano sad, it's happens when you use didSet with IBOutlets. Cause it's calls before awake(withContext context: Any?)
We can suppress this error if wrap it in DispatchQueue.main.async
#IBOutlet var statusLabel: WKInterfaceLabel! {
didSet {
DispatchQueue.main.async {
self.statusLabel.setHidden(true)
}
}
This has happened to me a few times and more times than not, it is because of a timer that is still firing in a just-previously dismissed WKInterfaceController that I did not catch.
Best thing to do aside from comparing ID's like in #staticVoidMan's answer is to read the call stack. In my case I was able to identify that the old timer was still firing based off these hints:
8 Foundation 0x00007fff214be867 __NSFireTimer + 67
9 CoreFoundation 0x00007fff207a8e3f __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
10 CoreFoundation 0x00007fff207a8912 __CFRunLoopDoTimer + 926
Here is the original call stack (for reference):
<MyApp.InterfaceController: 0x7fb3e4d2d020> has the Interface Controller ID 1EB00002
2021-05-26 14:44:06.632758-0600 MyApp WatchKit Extension[73392:3546879] [default] -[SPRemoteInterface _interfaceControllerClientIDForControllerID:]:2464: ComF: clientIdentifier for interfaceControllerID:1EB00007 not found. callStack:(
0 WatchKit 0x00007fff38d1a268 -[SPRemoteInterface _interfaceControllerClientIDForControllerID:] + 220
1 WatchKit 0x00007fff38d1bfff __54+[SPRemoteInterface setController:key:property:value:]_block_invoke + 340
2 WatchKit 0x00007fff38d12323 spUtils_dispatchAsyncToMainThread + 30
3 WatchKit 0x00007fff38d1be60 +[SPRemoteInterface setController:key:property:value:] + 179
4 WatchKit 0x00007fff38d057af -[WKInterfaceObject _sendValueChanged:forProperty:] + 706
5 WatchKit 0x00007fff38d2a5f8 -[WKInterfaceObject _setImage:forProperty:] + 50
6 MyApp WatchKit Extension 0x000000010955531d $s26MyApp_WatchKit_Extension25ActivityIndicatorDelegateC06handleE5TimeryyF + 813
7 MyApp WatchKit Extension 0x000000010955537a $s26MyApp_WatchKit_Extension25ActivityIndicatorDelegateC06handleE5TimeryyFTo + 42
8 Foundation 0x00007fff214be867 __NSFireTimer + 67
9 CoreFoundation 0x00007fff207a8e3f __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
10 CoreFoundation 0x00007fff207a8912 __CFRunLoopDoTimer + 926
11 CoreFoundation 0x00007fff207a7ec5 __CFRunLoopDoTimers + 265
12 CoreFoundation 0x00007fff207a2546 __CFRunLoopRun + 1949
13 CoreFoundation 0x00007fff207a18be CFRunLoopRunSpecific + 567
14 GraphicsServices 0x00007fff25b49fd3 GSEventRunModal + 139
15 UIKitCore 0x00007fff43290f24 -[UIApplication _run] + 917
16 UIKitCore 0x00007fff43295c0b UIApplicationMain + 101
17 WatchKit 0x00007fff38d0de65 WKExtensionMain + 800
18 libdyld.dylib 0x00007fff20202db5 start + 1
19 ??? 0x0000000000000001 0x0 + 1
)
Have you changed the name of your module? If this is the case then you have to go through your storyboard and update it manually for all the Interfaces you have.
Edit with steps to fix:
Go to the storyboard and for each interface open the Identity inspector, then delete what's in Module and press enter, the new module should get auto-filled.
We've added Today Extension to our app recently.
Its an extension with simple tableView to load data from our server, written in Swift.
But after the extension is online to our users, we've received lots of crash data from Crashlytics and also Apple is reporting same crash issue either.
However, we can't reproduce the crash, or even find the reason of crash, because is crashing on the widgetPerformUpdateWithCompletionHandler method which is called by the system.
Below is the detail of crash log, some information are replaced.
Crashed: com.apple.main-thread
0 MyAppWidget 0x100091d8c MyAppWidgetViewController.(widgetPerformUpdateWithCompletionHandler((NCUpdateResult) -> ()) -> ()).(closure #1) (MyAppWidgetViewController.swift)
1 MyAppKit 0x100603ab4 partial apply for thunk (PostService.swift)
2 MyAppKit 0x100626080 ServiceRequestPerfomer.(performRequest(A, complete : ([B]?, NSError?) -> ()?) -> ()).(closure #1) (ServiceRequestPerformer.swift:35)
3 MyAppKit 0x1006258d4 partial apply for ServiceRequestPerfomer.(performRequest(A, complete : ([B]?, NSError?) -> ()?) -> ()).(closure #1) (ServiceRequestPerformer.swift)
4 MyAppKit 0x100626b34 ServiceRequestPerfomer.((request in _3C50B415180DDC893FFCB75CD7EE7019)(A, complete : (response : Response?, error : NSError?) -> ()?) -> ()).(closure #1) (ServiceRequestPerformer.swift:144)
5 Moya 0x1004b7468 MoyaProvider.(requestNormal(A, queue : OS_dispatch_queue?, progress : (progress : ProgressResponse) -> ()?, completion : (result : Result<Response, Error>) -> ()) -> Cancellable).(closure #1).(closure #1) (Moya.swift:229)
6 Moya 0x1004b8968 MoyaProvider.((sendAlamofireRequest in _1A5616FEE5C423A992964CB19AABD52B)(Request, target : A, queue : OS_dispatch_queue?, progress : (progress : ProgressResponse) -> ()?, completion : (result : Result<Response, Error>) -> ()) -> CancellableToken).(closure #3) (Moya.swift)
7 Moya 0x1004b57b8 partial apply for MoyaProvider.((sendAlamofireRequest in _1A5616FEE5C423A992964CB19AABD52B)(Request, target : A, queue : OS_dispatch_queue?, progress : (progress : ProgressResponse) -> ()?, completion : (result : Result<Response, Error>) -> ()) -> CancellableToken).(closure #3) (Moya.swift)
8 Alamofire 0x1002cff64 Request.(response(queue : OS_dispatch_queue?, completionHandler : (NSURLRequest?, NSHTTPURLResponse?, NSData?, NSError?) -> ()) -> Self).(closure #1).(closure #1) (ResponseSerialization.swift)
9 libdispatch.dylib 0x1819e14bc _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x1819e147c _dispatch_client_callout + 16
11 libdispatch.dylib 0x1819e6b84 _dispatch_main_queue_callback_4CF + 1844
12 CoreFoundation 0x181f4cd50 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
13 CoreFoundation 0x181f4abb8 __CFRunLoopRun + 1628
14 CoreFoundation 0x181e74c50 CFRunLoopRunSpecific + 384
15 GraphicsServices 0x18375c088 GSEventRunModal + 180
16 UIKit 0x18715e088 UIApplicationMain + 204
17 libxpc.dylib 0x181c38ce0 _xpc_objc_main + 784
18 libxpc.dylib 0x181c3a9dc xpc_main + 200
19 Foundation 0x182a57d60 service_connection_handler + 170
20 PlugInKit 0x18929ac48 -[PKService run] + 544
21 PlugInKit 0x18929a8dc +[PKService main] + 56
22 PlugInKit 0x18929ac6c +[PKService _defaultRun:arguments:] + 20
23 libextension.dylib 0x18286a058 NSExtensionMain + 64
24 libdispatch.dylib 0x181a128b8 (Missing)
And the code of widgetPerformUpdateWithCompletionHandler
func widgetPerformUpdateWithCompletionHandler(completionHandler: ((NCUpdateResult) -> Void)) {
// Perform any setup necessary in order to update the view.
// If an error is encountered, use NCUpdateResult.Failed
// If there's no update required, use NCUpdateResult.NoData
// If there's an update, use NCUpdateResult.NewData
let options: [String: AnyObject] = [DCKPostPopularAttributeName : true.stringValue,
DCKPaginationLimitAttributeName : 5]
postService.posts(options: options) { (posts, error) in
let historyPosts = self.userDefaults.arrayForKey(MyAppWidgetViewController.WidgetPostReadIdentifier) as? [UInt]
if let historyPosts = historyPosts {
self.posts = posts!.filter({ (Post) -> Bool in
return !historyPosts.contains(Post.id)
})
} else {
self.posts = posts!
}
self.tableView.reloadData()
self.tableView.hidden = false;
self.loadingLabel?.hidden = true
self.activityIndicator?.stopAnimating()
let contentSize = self.tableView.contentSize
self.preferredContentSize = CGSizeMake(CGRectGetWidth(self.view.frame), contentSize.height);
self.loadMorePostsIfNeeded()
}
completionHandler(NCUpdateResult.NewData)
}
The strange thing is:
We haven't encountered the crash issue while we're using our Today Extension normally (It should show Unable to load if today extension crashes)
We didn't receive any issue from our users reporting that today extension isn't working.
We've found the same crash log on our device, but the today extension is working normally as 1. described. And also, the time of crash log recorded, I'm not using my phone!
So we're guessing it's a 「fake」crash, the crash is logged, but the extension didn't really crashed.
Does anybody facing the same issue?
Thank you!
Answering my own question,
#matt is right, Now I am calling the completionHandler only when data fetch task completes, instead of always call the completionHandler at the last of widgetPerformUpdateWithCompletionHandler method.
I didn't receive crashes anymore, the problem was solved!