iOS app crashes with EXC_BREAKPOINT (SIGTRAP) in AppDelegate.applicationWillResignActive - ios

Question

I have an app with very strange crashes that I have been unable to reproduce. I see these crashes in Xcode Organizer and in AppStore connect but not in crash tools (I tried Sentry and Bugsnag).
As far as I understand crash logs, crash occurs in applicationWillResignActive.
Incident Identifier: A15332F7-C7E6-4618-9FEF-7A2E6AD013FF
Hardware Model: iPhone14,5
Process: MyApp [1533]
Path: /private/var/containers/Bundle/Application/408766C6-5645-4592-9D89-CB8DE5D71A76/MyApp.app/MyApp
Identifier: com.myapp.identifier
Version: 1.2.3 (123)
AppStoreTools: 13A1030d
AppVariant: 1:iPhone14,5:15
Code Type: ARM-64 (Native)
Role: Non UI
Parent Process: launchd [1]
Coalition: com.myapp.identifier [899]
Date/Time: 2021-11-12 08:04:45.3781 +0300
Launch Time: 2021-11-12 01:20:00.0202 +0300
OS Version: iPhone OS 15.0 (19A346)
Release Type: User
Baseband Version: 1.00.03
Report Version: 104
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000100602734
Exception Note: EXC_CORPSE_NOTIFY
Terminating Process: exc handler [1533]
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 MyApp 0x0000000100602734 specialized AppDelegate.applicationWillResignActive(_:) + 168
1 MyApp 0x00000001005ff40c AppDelegate.applicationWillTerminate(_:) + 12 (<compiler-generated>:0)
2 MyApp 0x00000001005ff40c #objc AppDelegate.applicationWillTerminate(_:) + 56
3 UIKitCore 0x0000000186a34ddc -[UIApplication _terminateWithStatus:] + 244 (UIApplication.m:6876)
4 UIKitCore 0x0000000186122854 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 128 (_UISceneLifecycleMultiplexer.m:808)
5 UIKitCore 0x00000001863172e4 -[_UISceneLifecycleMultiplexer forceExitWithTransitionContext:scene:] + 224 (_UISceneLifecycleMultiplexer.m:482)
6 UIKitCore 0x0000000186a31a5c -[UIApplication workspaceShouldExit:withTransitionContext:] + 212 (UIApplication.m:3792)
7 FrontBoardServices 0x0000000195150c48 __63-[FBSWorkspaceScenesClient willTerminateWithTransitionContext:]_block_invoke_2 + 80 (FBSWorkspaceScenesClient.m:331)
8 FrontBoardServices 0x000000019510b6c4 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 240 (FBSWorkspace.m:352)
9 FrontBoardServices 0x0000000195150be0 __63-[FBSWorkspaceScenesClient willTerminateWithTransitionContext:]_block_invoke + 132 (FBSWorkspaceScenesClient.m:328)
10 libdispatch.dylib 0x0000000183346950 _dispatch_client_callout + 20 (object.m:560)
11 libdispatch.dylib 0x000000018334a3e8 _dispatch_block_invoke_direct + 264 (queue.c:489)
12 FrontBoardServices 0x000000019510cfa4 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 48 (FBSSerialQueue.m:157)
13 FrontBoardServices 0x000000019510c3e4 -[FBSSerialQueue _targetQueue_performNextIfPossible] + 220 (FBSSerialQueue.m:181)
14 FrontBoardServices 0x00000001951109f4 -[FBSSerialQueue _performNextFromRunLoopSource] + 28 (FBSSerialQueue.m:194)
15 CoreFoundation 0x00000001836f6030 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1972)
16 CoreFoundation 0x0000000183706cf0 __CFRunLoopDoSource0 + 208 (CFRunLoop.c:2016)
17 CoreFoundation 0x0000000183640ff8 __CFRunLoopDoSources0 + 268 (CFRunLoop.c:2053)
18 CoreFoundation 0x0000000183646804 __CFRunLoopRun + 820 (CFRunLoop.c:2951)
19 CoreFoundation 0x000000018365a3c8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
20 GraphicsServices 0x000000019ee6b38c GSEventRunModal + 164 (GSEvent.c:2200)
21 UIKitCore 0x00000001860000bc -[UIApplication _run] + 1100 (UIApplication.m:3457)
22 UIKitCore 0x0000000185d7dbe8 UIApplicationMain + 2124 (UIApplication.m:5013)
23 MyApp 0x00000001004a5b18 main + 68 (AppDelegate.swift:19)
24 dyld 0x000000010092da24 start + 520 (dyldMain.cpp:876)
Inside applicationWillResignActive I am fetching data from my local Realm and update values in UserDefaults.
class AppDelegate: UIResponder, UIApplicationDelegate {
let provider = Provider()
func applicationWillResignActive(_ application: UIApplication) {
if userDefaults.bool(forKey: UserDefaults.Keys.keyWidgetEnabled) {
provider.updateUserDefaults()
}
}
}
class Provider {
let database = try! Realm()
...
func updateUserDefaults() {
let defaults = UserDefaults(suiteName: "com.MyApp.identifier")
let currentDisplayDate = CalculationsHelper.getUTCSubmitDate()
let predicateHistoryDisplayDate = NSPredicate(format: "type=%# AND currentSubmitDate = %#", keyDBFood, currentDisplayDate.absoluteDate as NSDate)
let data = self.database.objects(History.self).filter(predicateHistoryDisplayDate)
mealTypesDB.allFoodTypes.forEach{ (type) in
let key = "widget-" + type.rawValue
let predicate = NSPredicate(format: "meal=%#", type.rawValue)
let kcal: Int = data.filter(predicate).sum(ofProperty: "kcal")
defaults?.set(kcal, forKey: key)
}
//set the date of the next day to update the button
let currentSubmitDate = CalculationsHelper.getLocalSubmitDate()
defaults?.set(currentSubmitDate, forKey: "widget-submitDate")
defaults?.synchronize()
if #available(iOS 14.0, *) {
WidgetCenter.shared.reloadAllTimelines()
}
}
}
I used to do this for every user every time they sent the app to background, but for a week now I've only done it for the small fraction of users who have my widget installed. But number of crashes almost didn't change so I think that this bug is not related with Realm or UserDefaults.
As far as I can tell from AppStore connect, I've always had this bug, but only with the release of iOS 15 has the number of crashes dramatically increased. I'm not really sure how this can be resolved and what exactly has changed in iOS 15 that could provoke such a dramatic increase number of crashes.
I found this thread https://developer.apple.com/forums/thread/106261 and tried renaming all my images in the project so that the file names match the name in Assets, but that didn't work.
Does anyone have any idea what I can do to at least figure out the cause of the crashes?

Answer 1

I contacted Apple TSI and they told me to check that the object inside the applicationWillResignActive and applicationWillTerminate method is nil. And to my surprise at the moment of calling applicationWillTerminate the object is really nil.
But can anyone explain how this is possible? This object is initialised in didFinishLaunchingWithOptions and I never make it equal to nil during the app life cycle. Is it possible that iOS is trying to terminate the application for some reason (not enough memory, for example) and tries to remove all objects from memory one by one, and when applicationWillTerminate is called, object is already removed from memory and therefore it is nil? But at which point it's allowed to nil out a variable of a running class?
UPDATE:
I got a response from the Apple team and I think it's very interesting. They said that didFinishLaunchingWithOptions will ALWAYS be called before other lifecycle delegates for
the "standard" lifecycle like applicationWillResignActive and
applicationDidEnterBackground. However, that's NOT the case with applicationWillTerminate. The
termination process can occur outside the normal lifecycle flow and, at
least in theory, there's not reason it couldn't occur before
didFinishLaunchingWithOptions is actually called.
So if I have an optional variable in AppDelegate that is initialized inside didFinishLaunchingWithOptions, it can still be nil in applicationWillTerminate. This is what causes some users to crash.

Answer 2

Are you calling applicationWillResignActive yourself? It looks like you call it from AppDelegate.applicationWillTerminate. You should never call the UIAppDelegate methods yourself, that is an anti-pattern. I'm not sure that causes the crash though, but you may want to introduce a separate method which you call from both.

Answer 3

The fact that you are using a custom crash reporter (Sentry, Bugsnag, ...) could be an issue. When your app crashes, Apple's crash reporter can get confused and the reported line you get will be completely wrong.
You can find more details provided by an Apple engineer on this Apple dev forum post. He recommends only using Apple's own crash reporter because third-party crash reporters are tied to your app process and can corrupt the stack trace when they try to get it while your app is crashing which results in a wrong report in Xcode.