Message Sent to Deallocated Instance iOS [_UILayoutGuide isDescendantOfView:]: - ios

Trying to find the source of this EXC_BAD_ACCESS in my iOS App. I get the following on the console:
[_UILayoutGuide isDescendantOfView:]: message sent to deallocated instance 0x7fd14037d0e0
And have used Zombies to try to track this down:
I can't find the source of the problem. Double clicking on any of the stack traces in Zombies doesn't lead to any of my code.
Hope you can help - before I bang my head too hard off the wall!
-Thanks

I finally found the answer - the problem was a constraint in the Storyboard.
The constraint was not "installed", but I found that by deleting UI elements one by one I could track down the problem constraint. No apparent reason why it would cause a crash like this, but deleting it has fixed the issue.

Related

How to fix this strange crash with keyboard

I have been seeing some odd crashes with the keyboard for some of the users that are live.
Looks like a KVO issue with UIWindow.
We are not adding any observers for key path windowLevel, so wondering what is causing this crash or how to debug this.
An instance 0x12c653e70 of class UIRemoteKeyboardWindow was
deallocated while key value observers were still registered with it.
Current observation info: NSKeyValueObservationInfo 0x12d3e6100
NSKeyValueObservance 0x1196e01a0: Observer: 0x1273223f0, Key path:
windowLevel, Options: Context: 0x0,
Property: 0x12c633980>
Also this crash is so random, I have never encountered this personally but got this via Crashlytics. Any help would be appreciated.
Have anyone else experienced similar issues.
It would be nice if you had provided some sample code. But I guess you may be removing all observers of your UIViewController at once and in wrong place. Move the code for removing observers to "viewWillDisappear" and it may solve it.
Another guess is you are changing an attribute of keyboard when it has been deallocated.
My other guess is that you may have a "weak" property of keyboard. If so, change it to "strong" and it will solve the problem.

Adding a breakpoint to breakpoint navigator for a Core Data error

I'm trying to track down a bug in an app which logs an error in the simulator, but doesn't crash in the simulator or on my testing device. I think I've got a handle on what to do once I can figure out where the problematic code is located, but I'm having a heck of a time figuring out what call is generating it.
CoreData: error: Failed to call designated initializer on NSManagedObject class "OneOfMyManagedObjects"
I'd like to add a breakpoint that stops execution on that error. How would I set the breakpoint navigator to stop execution when that error is logged in the console?
What I've Tried:
So far, I threw some log statements in AppDelegate.swift and the initial ViewController to "see what's going on". Additionally, I've thrown in some manual breakpoints in hopes of tracking down the issue that's generating the console error, but it's taking forever and a day to step through everything. Given the issue lives somewhere between AppDelegate and viewDidLoad of the initial ViewController, I'm baffled why it's taking me so long to spot the problem.
I've added an exception breakpoint for all exceptions in the breakpoint navigator, but this error doesn't appear to be enough to stop execution. I do think it's enough to cause a problem for a minority of users, which is why I'm trying to clean it up.
Special thanks to pbasdf for pointing me in the right direction.
My app uses a TabBarController with 4 tabs. The initial tab is tab 0, so I was looking for a problem between AppDelegate.swift and InitialVC's viewDidLoad. In reality, my problem lived on Tab3ViewController where OneOfMyManagedObjects are displayed.
I had a global variable set on Tab3ViewController that looked like this:
// this was the problem
var oneOfMyManagedObjectsToEdit = OneOfMyManagedObjects()
// I changed it to this and the error went away
var oneOfMyManagedObjectsToEdit: OneOfMyManagedObjects?
Thank you for pointing me in the right direction towards resolution of this problem.

How to debug EXC_BAD_ACCESS

I've been debugging for several hours, read some articles but still can't find what's wrong.
I've switched on ARC, but I found that my BIDGameScence will be deallocated strangely, and I don't know why.(I've checked that all pointer to BIDGameScene is strong.) I went through call stack when selector dealloc was called, but there's no selector written by myself in the stack(I think the last stack frame is a function used to send a message).
I also tried Zombies, but I just got Message send to deallocated object. An article says that I should use malloc_info, but I'm using lldb and got malloc_info is not a valid command.(I found that there is no gdb in my XCode.)
What's more, I added a NSLog statement in applicationDidReceiveMemoryWarning, but I did't find it in the logging.
Finally I tried to use Product->Analyze, but got nothing.
So, how to debug this error?
I'm using XCode 4.

iOS EXC_BAD_ACCESS: How to debug?

I am getting an EXC_BAD_ACCESS. I know what this usually means: Trying to access an object that doesn't exist (anymore) is the most likely cause.
So, where do I find that?
I have read numerous posts on the internet, and they all say:
"Enable NSZombie" in the scheme.
Now when I run the debugger, for what should I look? I can not see any difference...
Note: This is not about a perticular error in my code, but generally how to use the debugger with NSZombie enabled
What I would do it will be to locate a breakpoint just one line above the green arrow showing the EXC_BAD_ACCESS error. Then run again your code and reproduce the steps to generate the crash.
When you get to your breakpoint you can check that your objects are valid objects using right click and print description in the left side of your console within Xcode or typing the command 'po' within the console section in XCode. That's how I usually detect the errors.
Something useful is to trace the stack once the debugger stopped. It show in the left panel the threads and chain of invocations of the methods before the break point.
Hope this helps and hope my description of the alternative in how to track the error helps.
Write code in #synchronized(){} block.
Try this:
#synchronized (self){ //Your Code }

Is there a method that always gets called right after didSelectRowAtIndexPath?

I'm working on an iPad app in which I have a table view. When the user selects a row in the table, I use didSelectRowAtIndexPath to open a popover. I'm getting an error message saying "message sent to deallocated instance" when I try to use a certain button. I originally though the errors was getting thrown by the popover (in it's viewDidLoad or something), so I put a breakpoint in and stepped through the code. To my surprise, I was able to step all the way through the loading of the popover and the rest of the didSelectRowAtIndexPath on my table view (which actually just involves stepping out of some if blocks). The error then gets thrown when I get a couple steps into the automatically generated code that doesn't appear in any of my class files (that looks like 0x0010d71d <+1164> mov 0x6...).
So, my question is, how do I find where this error is being thrown? Is there another method that is automatically run after didSelectRowAtIndexPath that could be getting messed up somewhere?
Enable NSZombieEnabled in your DEBUG build (see How do I set up NSZombieEnabled in Xcode 4?) to locate instances of objects you're accessing that have been deallocated/released.
Also, consider upgrading your project to ARC, which will likely resolve memory management issues like this.
Okay, everyone's responses lead me to find malloc error -[CFString release], which helped me figure out I had a string in my popover that I alloc in viewDidLoad by
myString = [NSMutableString stringWithString:[myGlobalFunctionClass getMyString]];
Since I alloc it this way, it gets set to autorelease. The problem was I was explicitly [myString release]; and myString = nil; in viewWillAppear. Removing the release and =nil parts cleaned up my error.
To answer the actual question that I posted, I believe the autorelease wasn't firing until the simulator actually tried to display the popover (which would run after didSelectRowAtIndexPath). Since that occurs after I explicitly [myString release] in viewWillAppear, it was trying to autorelease something that was no longer there. Just to reiterate, the proper way to do it was let it autorelease at the end, and not [myString release] anywhere in my code.
Can someone verify that this is correct? As I mentioned in my comments, I'm still very new to iOS development. I have a feeling at the end of this project, I'm going to be able to go back to first stuff I did in it and make dozens of improvements in terms of doing things more efficiently and more in accordance with best practice.

Resources