I'm experiencing a strange issue with my application that causes it's provider to crash after random intervals of time.
I’ve been going through some pretty lengthy debugging sessions with the app in order to replicate the sporadic issue of the provider going away without a reported cause, and I managed to have a debugger attached while it was happening. The call it seems to crash on is an EXEC_BAD_ACCESS signal from an iOS internal that’s invoked when we try to access a particular portion of storage that is shared between the application and the provider. The odd thing about this, is that previously I was using the keychain to share the data between the application and the provider, having gotten this error from an iOS internal while doing that, I moved it over to a storage method that Apple provides called “UserDefaults”. Now, with a completely different method of storage for the data, I still seem to get the same error, from completely different internal calls. This leads me to believe that something else is going on, and this portion of the logic failing is just a consequence of that. Looking closely at the iOS system logs I found that at the time of the crash the device reported this:
```
memorystatus: freezing (general) pid 6331 [MyApplication]…skipped (too much shared memory)
```
There are two odd things about this.
- This is referencing the container application, not the provider.
- This is reported AFTER the provider is closed with no stated reason.
The process that happens here is:
This can happen synchronously, as the container application is updating it every X interval and the provider is reading it every X interval, according to apple’s documentation this shouldn’t be a problem.
* The container application updates the property.
* The provider reads the property.
What I feel may be going on is that the container application runs out of shared memory, but still updates the address that the provider will read from. Then when the provider tries to read from this address, it dies with an EXEC_BAD_ACCESS.
My next thought was to attempt to profile both the container application and the providers memory usage. However, attempting to profile the provider memory (which is an application extension) will immediately crash the provider. (This is a bug that i’ve experience ever since i started working with iOS Extensions).
The fact that it still gets the exact same signal in the same spot of logic while using completely different system calls and a completely different storage method baffles me.
Previously, it would get an EXEC_BAD_ACCESS on `SecItemCopyMatching(query as CFDictionary, &item)` which reads the data from the keychain.
Now, it gets an EXEC_BAD_ACCESS on `preferences.integer(forKey: "current_zone_index")` which reads from UserDefaults. These both use completely different storage methods, but it’s still failing at that exact same spot regardless.
