Over the last few months we are facing the following issue intermittently in the app we are developing.
The App: It's a fairly complex iOS app with a tabbar-based navigation developed in Swift. It has a good number of pushes and presentations.
The issue: We sporadically encounter app crashes when presented view controllers are dismissed. These crashes are not reproducible, and you cannot find a scenario where this will definitely happen. The app does not crash indicating a line in our code. It is observed in various versions of both iOS 8 and iOS 9 devices. We never get any log pertaining to the crash.
As seen in the images, there's not much to go on with. But, on constant observation of crashes over the months, we've noticed something on the Thread 1 in the left bar of the Xcode window. The stack leading to the crash will always end with [UINavigationController viewWillAppear:]
Also, as seen in the stack is a line indicating '_CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER...' which made us suspect that an NSNotification selector is being called on a deallocated class. For this, we made sure that we removed all NSNotification observers in all classes before deallocations and also had logs in deinit methods of every class and made sure they were deallocating when required. This still didn't solve the problem.
Can somebody please help us with this issue?
Are you using a delegate pattern? If you are, then the delegate properties should always be declared as weak. I am guessing you have a strong reference to a delegate property somewhere and a controller that uses notifications isn't getting deallocated.
Related
I was searching crash logs of my app, and I've seen this (which occured quiet a few times, not just once or twice):
As seen above, notification center posted a memory warning notification, and it was somehow forwarded to a CALayer. I've also seen instances of didReceiveMemoryWarning: messages sent to other deallocated objects such as UIImageViews or even private _UINavigationBarBackground objects, when zombies were enabled on my debugger, too, crashing my app. Why would this happen?
NSNotificationCenter only keeps weak references to observers.
What's probably happening is that you have one ore more objects somewhere that register for UIApplicationDidReceiveMemoryWarningNotification, but which never unregister (thats a bug). Since NSNotificationCenter only keeps weak references to those objects it doesn't notice when they are dealloc'd and their memory is reused for other objects such as CALayer etc, which do not implement a method named didReceiveMemoryWarning.
This seems like a memory management issue. Typically, the memory warning would be sent to a currently-existing UIViewController, which lives at some hypothetical location X in memory.
But at runtime, instead of finding your UIViewController at location X as expected, it found some other object, like a random CALayer or UIImageView, which does not know how to respond to didReceiveMemoryWarning:. This results in the crash you're seeing.
Does your project use ARC? Enable it if its not already, that should reduce the frequency of these errors. If you're using manual retain/release, it is likely there is some error in your implementation.
If you have any code that does funny things with memory, or any code that does hacky things with view controller transitions, those are possible culprits, I'd post that code.
Also, try manually sending a memory warning to your app as soon as it is done starting up, to see if the issue manifests immediately, or if the app needs to run for a while before it occurs.
In our app we show the Camera modally on top of another UIViewController. On iOS 8.x only, about 1/10 of the time if you zoom you wind up with a crash:
PLImagePickerCameraView didHideZoomSlider:]: message sent to deallocated instance
There is an existing SO post which has a supposed workaround - How-to find out what causes a didHideZoomSlider error on IOS 8? - but every variation I have tried fails to solve the crash. The suggestion involves putting a delay before dismissViewControllerAnimated:completion: . No matter what delay I try I can still reproduce the crash.
It only occurs (1) if you zoom the camera view (2) either choose Cancel or take a photo and exit the camera, all shortly before the zoom indication animation fades away. It appears to be a problem in iOS 8.x which Apple hasn't fixed. It crashes in Apple's code with no involvement in anything we have.
I do see "Snapshotting a view that has not been rendered results in an empty snapshot. Ensure your view has been rendered at least once before snapshotting or snapshot after screen updates." but this seems to be unrelated and is also referring to code inside the UIImagePickerController not anything we are doing.
I am about to deal with Apple DTS to see if we can find some way to avoid this or what in the environment might be causing this to happen. I thought to ask here in case anyone has another idea.
This crash did not occur under iOS 7.X. Happens on any model iPhone or iPad.
The answer from Apple is "it's a bug, file it in Radar" which of course says nothing about when it will be fixed. There is no workaround other than to tell users to wait a little until the slider fades (which our support people tell the users). There is nothing you can do other than implement your own camera and zoom support and do it yourself correctly.
Perhaps Apple will fix it in 8.2.
Boy, this is frustrating.
I sent in my app to Apple after months and months of development. It was quickly rejected due to the fact that they said it was unresponsive at the home screen. Here is the screenshot they sent me:
Now, when I build the exact archive of the app that I sent them, I have no such issues:
The buttons were created in the storyboard file and were IBOutlets, but the highscore label that you see was created programmatically. Is it possible that the storyboard file didn't upload properly? I have already messaged them in the resolution center about it and tried to submit it again to see if it would work next time, but I was wondering if anyone knew anything about this issue.
From above screenshot, I've understand something that issue related with network error. See, they were tested with flight mode. According to apple guidelines, it should be go on in home screen without much more delay. At least show an alert for this issue. Just test with this scenario, you will get this.
When they said it was unresponsive, it may be due to the fact that its stuck for certain reasons, check if you make any API call at the viewLoad method, also, if the UI may turn unresponsive incase you are performing some heavy operation on the main thread, try using a background thread of these operations
It's been an extremely long time, but I thought I'd say what was wrong in case anyone comes across this in the future. Basically, I had created the buttons in Interface Builder but was re-instantiating them in viewDidLoad of my view controller. Since IBOutlets are weak properties, they were thus being released. Why that wasn't happening when I ran it on my computer, I have no idea. Still puzzles me to this day.
I have a tab bar application where in one tab bar, there are 7 separate UISwitch instances. When I run the application and go to the tab bar with the switches, I then call
[self dismissModalViewControllerAnimated:YES completion:nil];
Then I call
[self presentModalViewController:myController animated:YES completion:nil];
When I return to the same tab bar with the 7 UISwitches and I touch one of them, changing the state, the app crashes. So I enabled NSZombie objects and ran the app again and this time when it crashed, it gave the error message
[UICGColor retain]: message sent to deallocated instance 0x9ace8a0
This means that the object was double deallocated, and I obviously didn't try doing this. So, I did some research and found that I could find the line(s) of code that cause it to double deallocate by profiling the app with an NSZombie template, using the Xcode built-in instruments. I then intentionally caused the app to crash, and the I received this.
I can clearly see that my ChessTimer library is releasing the object one too many times, causing it to double deallocate. So, I next looked at the exact line(s) of code that are doing this and found this
I can see the lines of code now that are directly causing the problem. When I remove them, the app runs fine. The problem, however, is that these lines of code are an important design element in my app that I must keep. I don't even know why these lines of code are causing the app to deallocate that object again. How can I either neutralize this deallocation or find another workaround? All help is appreciated.
I'm struggling with the following scenario and could use some different perspectives to shed some light on me:
I have a self.backstack which is an array of sections to go "back" to when you hit the back button. I'm getting an EXC_BAD_ACCESS when the back button is hit in a particular situation, but I'm not sure which object the code is mad about because everything seems there.
If you look on the bottom left of the image you'll see that self, backStack, and userInfo are all there. Not only that but their respective prints on are logged in the bottom right.
Any thoughts on what the problem might be? Thanks.
I suspect you have an observer of the notification which has been deallocated before it unregistered for the notifications.
Notifications are synchronous, which means that on the line you are crashing on, it is trying to run all of the observer callbacks. Check everywhere you are registering for these, and make sure the objects are either retained elsewhere, or are being properly unregistered (removeObserver iirc) when they are released.