I have a UINavigationController, that I use to transition between an 'Inbox' and 'Outbox' view controller.
It works fine in iOS6, but when I target iOS7, I get the following:
-[_UINavigationBarBackIndicatorView setAlpha:]: message sent to deallocated instance 0xc383c90
This happens when I call
[rootNav pushViewController:outbox animated:NO];
I've enabled Zombies and used the Allocate instrument to get some more information.
I've attached a screenshot of what I found.
Unfortunately, I have no idea what to do with this information. Does anyone have any ideas?
Also, this app does not use a back button. Maybe this is the issue?
Thanks!
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.
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.
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.
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 have just developed an iPad app to the point of testing, but did it in iOS 4.3. Now I've updated to 5.0 in the simulator and also went through Apple's steps to test on my iPad which runs 5.0
In the 4.3 simulator all works fine. But in the 5.0 simulator and on the iPad all of my popovers that originate from UIButtons crash the app. I have a popover coming from a navbar button which works fine.
Each popover that crashes will display its contents (a UIWebview with a pdf file), but when I then click anywhere on the screen the app crashes (within the popover and outside).
I can post some code, but hope that this description helps give someone an idea. I don't manually dismiss the popover or check if it is open, but since this doesn't only occur by trying to touch its launching UIButton I don't think that's why it's happening. Plus it works as is under 4.3
Edit: This is solved now thanks to Stephen's comment. I added into the popOver's content viewController:
- (void) dealloc {
[webView release];
[super release];
}
Usually I would call [super dealloc] instead of [super release], but [super dealloc] didn't fix the exception (exc_bad_access). Hopefully I haven't put a sloppy patch on the problem!
I had a thread started to collect bugs like this, but the forum police quashed it. Suffice it to say that iOS 5 is riddled with incompatibilities.
I can't say with any certainty what your problem is, but there's a good chance it has to do with the changes to UINavigationController, which caused UIViewController's navigationController to be nil for popups, with parentViewController taking its place.
Unfortunately, parentViewController is new, so you must, eg, test respondsToSelector:#selector(parentViewController) and take parentViewController if it exists, otherwise navigationController.
Had to add this logic in about 30 places in an app we have.