Swift Crash "Exc_Breakpoint 0X0000000... "

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

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.

iOS 13 - Crashed: com.apple.main-thread EXC_BREAKPOINT (CoreFoundation)

As par Alex's solution,

It seems that the dyld3 saves the generated clojure files in the app
tmp directory and if you use NSFileProtectionComplete the closure
files have this property too.

To generate a crahs close the app, lock the phone, send a push that
will wake up the app and then the crash is generated.

The solution seems to be simple, just change the permissions for the
app tmp direcptry to
NSFileProtectionCompleteUntilFirstUserAuthentication and the app will
not crash. I really don't know why apple did this.

This worked for me.

Reproduction & Test

Rayns comments

You don't necessarily need to use push notifications to reproduce the
issue. If your app is configured to use complete file protection in
the entitlements, any code that runs while protected data is
unavailable will cause the app to crash. For example, my company's app
has a background task that takes longer than 10 seconds to execute.
Since protected data becomes unavailable around 10 seconds after
locking the device, the app will crash before the background task can
finish executing (despite having more time available on the
assertion).

Related Topics