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.
Related
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.
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.
When I run my app in simulator everything is fine, but when I run in device it is crashing.
Reason is I am pushing one xib from my storyboard and it's working well but when I press the back button it is crashing and [myxib class name method] message sent to deallocated instance 0x1fc65600. But in simulator it's fine, is that due to memory leak?
It is pointing to:
0x311ad468 trap <--- Thread1:EXC_BREAKPOINT (code =EXC_ARM_BREAKPOINT ,subcode=0xdefe))
[self.navigationcontroller pushviewcontroller:obj animated:YES];
I solved it,first thing is iam retrieving some values in previous class from someother class,so when iam out of focus that value transaction is throwing exception,so what i done is i disable the back button for some seconds
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.
I am writing an iPad app which uses an AVPlayer to display a video. There's buttons to jump to various parts of the video, and when the user rotates the device, I change the size of the view which holds the AVPlayer layer.
My problem is that after a certain amount of device orientation changes and jumps around the video, the app crashes.
I have NSZombie enabled - this doesn't break.
I have a breakpoint enabled in my code to catch exceptions - this doesn't break.
I have run instruments and the code isn't leaking.
Allocations simply shows the "Overall Bytes" growing and growing with every action until it hits 14 meg and the pad crashes.
I feel like I have no way of getting to the bottom of this. Am I missing some trick to solving this? Does AVPlayer need some special treatment when being released?
ANY HELP, MUCH APPRECIATED.
Use instruments to check your Allocations. I recently had a very similar problem where there were no memory leaks but my Overall Bytes kept growing every time I launched a particular ViewController (and it would eventually crash).
It turned out that the ViewController itself was a strong reference as a delegate to another class (oops) and each time I dismissed the ViewController that other class still had a reference to it. Therefore each time I launched and dismissed this ViewController I would create another instance of it that would never die (and never leak).
Your exact problem may be different but you should be able to see the reason for your Overall Bytes growing by checking out your Allocations.