ViewController respondsToSelector: message sent to deallocated instance (CRASH)

Use Instruments to track down deallocated instance errors. Profile your application (Cmd ⌘+I) and choose Zombies template. After your application is running, try to crash it. You should get something like that:

Click on the arrow next to address in the popover to show object that was called after it was deallocated.

You should see now every call that has changed retain count of this object. This could be because sending directly retain/release messages as well as draining autorelease pools or inserting into NSArrays.

RefCt column shows retainCount after action was invoked and Responsible Caller shows class name and method in which it was performed. When you double click on any retain/release, instruments will show you line of code where this was performed (If this isn't working, you can examine call by selecting it and choosing its counterpart in Extended Detail pane):

This will let you examine all the retainCount lifecycle of object and probably you'll find your problem right away. All you got to do is find missing retain for latest release.

had a similar problem. In my case a viewController needed to get navigationController events, so it was registering as the navigation controller delegate:

 self.navigationController.delegate = self;

The crash occurs when that controller was dealloc'ed but was still the delegate for the view controller. Adding this code in dealloc had no effect:

-(void) dealloc{    if (self.navigationController.delegate == self)    {        self.navigationController.delegate = nil;    }

because at the point that dealloc is called, the view controller has already been removed from the view hierarchy, so self.navigationController is nil, so the comparison is guaranteed to fail! :-(

The solution was to add this code to detect the VC leaving the view hierarchy just before it actually does so. It uses a method introduced in iOS 5 to determine when the view is being pop'ed and not pushed

-(void) viewWillDisappear:(BOOL) animated{     [super viewWillDisappear:animated];   if ([self isMovingFromParentViewController])   {      if (self.navigationController.delegate == self)      {           self.navigationController.delegate = nil;      }   }}

No more crashes!

For anyone who can't solve it, here are some other techniques:

https://stackoverflow.com/a/12264647/539149

https://stackoverflow.com/a/5698635/539149

https://stackoverflow.com/a/9359792/539149

https://stackoverflow.com/a/15270549/539149

https://stackoverflow.com/a/12098735/539149

You can run Instruments in Xcode 5 by clicking the project popup->Edit Scheme...Profile ->Instrument and choose Allocations or Leaks, then profile your app, then stop Instruments, click the info button in Allocations and "Enable NSZombie Detection".

However, for the messages that come directly from the com.apple.main-thread, this probably won't reveal anything.

I banged my head on this for over two hours and the answer turned out to be an over-release, which I discovered by commenting out a copy of my project by brute force until I found the culprit:

[viewController release];viewController = NULL;

The problem is that release doesn't set the variable to NULL.

That means that setting it to NULL calls release again, decrementing the refcount and freeing the memory immediately until later when the variables that reference viewController are finished with it.

So either enable ARC or make sure your project consistently uses release or NULL but not both. My preference is to use NULL because then there is no chance of referencing a zombie but it makes finding where objects are released more difficult.