I'm using Realm as my backend and it is working properly but after sometime as continue using the app it gets crashes rising the message in console as
**[RLMRealmConfiguration copy]: message sent to deallocated instance 0x7fdea71dfa70**
As in my app the insertion , deletion or updation done after a specifice time interval and this error don't go to the point where it get crashed after using the exception break point also.
Thanks.
Related
Trying to debug a crash that a user is having that isn't showing up in our crash reporting tool or in our log files. Have a theory it might be down to memory pressure, but not sure if applicationWillTerminate will be called if iOS kills an app application in the foreground. We write to our log file in applicationWillTerminate but it apparently isn't being called during this crash.
If the app crashes, no lifecycle method is called reliably. Instead you can create & register a global exception handler which gets invoked in this case:
func exceptionHandler(exception: NSException) {
print("*** UNHANDLED EXCEPTION ***")
print(exception)
print("CALL STACK:")
print(exception.callStackSymbols.joined(separator: "\n"))
}
Register this function using NSSetUncaughtExceptionHandler, e.g. in your UIApplicationDelegate.application:didFinishLaunchingWithOptions::
NSSetUncaughtExceptionHandler(exceptionHandler)
System had to trigger applicationWillTerminate if it up to kill the app. However you can't be sure how much time you have to before app actually will be killed. Maybe it just not enough time to write the log. Before killing app due to memory consumption system should send memory warning. You can test last one by simulating memory warning on Simulator. If applicationWillTerminate didn't called then want terminated by system and you crash not related directly to memory consumption.
I use a Firebase realtime database in an iOS app and I get a crash report through Firebase's crash reporting at [FIRDatabase assertUnfrozen] called from [FIRDatabase setPersistenceEnabled:]. (There's also a variation of these reports where the source is FIRDatabaseConfig rather than FIRDatabase)
In my app delegate's application:didFinishLaunchingWithOptions: method, I load the Firebase config from a file and then set persistence to enabled. For about 1 out of every 200 users this causes the crash with assertUnfrozen. Am I initializing Firebase in an incorrect way, or is there anyone with an idea about what's going wrong?
Calls to setPersistenceEnabled must be made before any other usage of FIRDatabase instance.This is reason for the crash, so check whether you are using FIRDatabase instance before calling setPersistenceEnabled.
In my case, I was using FIRDatabase instance in applicationDidEnterBackground and I had used setPersistenceEnabled in launchController.As soon as we open the app, before launchController is called, make the app go into background.Then, applicationDidEnterBackground gets called and FIRDatabase instance is used before calling setPersistenceEnabled.So, I removed firebase code from applicationDidEnterBackground and wrote it after setPersistenceEnabled is called.
When running my app on device, it crashes right when I initiate my AvPlayer to stream an mp3. However, it works fine on simulator.
I have tried to run it through Zombie and I get the following error message when it crashes : "An Objective-C message was sent to a deallocated 'UIActivityIndicatorView' object (zombie) at address: 0x108c020e0"
I am using an Activity indicator in previous scenes but I have tried to remove it completely, leaving no line of code mentioning any UIActivityIndicatorView and I still get the same error.
Any idea of how to deal with this? Can it be linked to the system activity indicator displayed the status bar?
Many thanks for your help
It's a crash because of abusing appearance API not as documenting (setting a property not marked with UI_APPEARANCE_SELECTOR).
For reference, see here.
Every time a user taps the home button while my app is active, I am getting the following exception. Slight caveat - The example exception below references NSCFString. However, the type of object that gets sent this message, and thus causes the exception is totally random. It could be an NSData or an OS_dispatch_queue_specific_queue.
[__NSCFString didEnterBackground:]: unrecognized selector sent to
instance 0x155344c0 * Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: '-[__NSCFString
didEnterBackground:]: unrecognized selector sent to instance
0x155344c0
Happens every single time the app is resigned active, but the object receiving the message is never the same.
I assume this is some sort of memory issue but am having trouble tracking it down. Mostly because nothing in my code ever directly sends/receives this message, or is registered to receive the UIApplicationWillResignActiveNotification. Also, there is nothing in my appDelegate for the applicationDidEnterBackground:application method.
Has anyone ever seen this type of behavior? And if so, what is the best way to debug? Or maybe another way, what sorts of objects would be automatically sent the didEnterBackground message that I am clearly mismanaging?
It sounds like you have a zombie.
A zombie is an object that gets called after it is deallocated. Often, the memory address of the object is then used for another object, so the message goes to the wrong object.
Do you have code that registers one of your application objects for a "did enter background" notification (UIApplicationDidEnterBackgroundNotification) using the method addObserver:selector:name:object:? And does that notification specify a selector of "didEnterBackground:?"
My guess is that you're registering for UIApplicationDidEnterBackgroundNotification notifications, and then the notificationObserver you're specifying is being deallocated. That would cause the exact behavior you are describing.
BTW, you might want to run your app using the zombies instrument, or turn on the NSZombies environment variable to look for zombies. Then press the home button to cause the crash and see what Xcode/instruments tells you.
This is what I am doing in my project
User does login with facebook, once successful login the app starts downloading of all images from sever in background queue. I have written the saving of image to core data in a block and submit the block to background queue so that main thread will be not be blocked.
Problem:
Once user does login, he goes to settings screen where he logs out of the app. At that point there might be blocks in the queue and they will be executing saving of the images to core data. My app crashes due to uncaught exception * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Object's persistent store is not reachable from this NSManagedObjectContext's coordinator.
When I log out I clear the persistent store and coordinator of the app. Those are global objects to the app. But I am not sure why this crash is happening?
Thanks
This issue has been fixed. The issue was due to clearing the store of the app when user taps on logs out. When it gets cleared there might be some blcoks in the queue which are still executing and when they try to save the image to core data, the app gets crashed. Now I have fixed this buy adding the clear store as a part of block and submitted to same queue so that the store gets cleared once all all blocks gets over from queue.