ViewController response sToSelector: 发送到释放实例(CRASH)的消息

好的,是这样的,我 仇恨提出关于调试和崩溃的问题。因为我通常自己处理它们,但我只是 不能得到我的方式,甚至在 已经看过很多问题了之后。

好的,问题就在这里,我发现我的应用程序在堆栈跟踪中时断时续地崩溃:

*** -[ViewController respondsToSelector:]: message sent to deallocated instance 0x1e5d2ef0

哪里 ViewController可以变化,有时我的代码崩溃的地方,有 没有相关性的特定 ViewController,并不拥有或调用它。

此外,为了获得控制台跟踪,我已经启用了 Zombie,否则我将根本不会获得控制台打印,我将只获得: objc_msgSend,我知道这意味着我正在发布消息。但是我找不到它在哪里... 我真的被卡住了!通常我的 一直都是调试我的崩溃,所以我真的卡在这一点。

同样,这个崩溃在不同的地方在不同的时间,断断续续。它坠毁的地方几乎与 ViewController相关。我觉得这很让人困惑。

你需要我的密码吗?我有 很多的文件,因为它是崩溃在不同的地方,分发我的代码将是一团糟!

我尝试过添加符号断点,但没有成功,而且 iOS 的 Instruments 应用程序中没有 Zombie。我不能在模拟器上运行我的应用程序,因为它有不支持的架构框架。

谢谢大家。

45119 次浏览

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:

enter image description here

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

enter image description here

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):

enter image description here

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.

Had the same problem in OS X.

To solve this not enough - (void)dealloc method as @SoftwareEvolved already said. But unfortunately - (void)viewWillDisappear is available only on version 10.10 and later.

I introduced custom method in my NSViewController subclass where set all the zombie-dangerous references to nil. In my case that was NSTableView properties (delegate and dataSource).

- (void)shutdown
{
self.tableView.delegate = nil;
self.tableView.dataSource = nil;
}

That's all. Each time I'm about to remove view from the superview need call this method.

I had met the same problem in iOS yesterday. I have made IAP in App "About" subview, and I have added Transaction Observer in "About" viewDidLoad. When I purchase for the first time, no problem, but after I back to main window and enter about subview to purchase again, the problem "message sent to deallocated instance" happened, and the App crashed.

- (void)viewDidLoad
{
[[SKPaymentQueue defaultQueue] addTransactionObserver:self];                                           object:nil];
}

After I remove Transaction Observer in dealloc, the problem is solved.

- (void)dealloc
{
// Even though we are using ARC, we still need to manually stop observing any
// NSNotificationCenter notifications.  Otherwise we could get "zombie" crashes when
// NSNotificationCenter tries to notify us after our -dealloc finished.


[[SKPaymentQueue defaultQueue] removeTransactionObserver:self];
}

I had a very similar issue and I figured out it was due to navigation controller delegates set.

The below solved my issue,

- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];


if (self.navigationController.delegate != self) {
self.navigationController.delegate = self;
}
}


-(void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];


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

I had the same Problem.It was difficult to find which delegate cause issue, because it does not indicate any line or code statement So I have try some way, Maybe it becomes helpful to you.

  1. Open xib file and from file's owner, Select "show the connections inspector" right hand side menu. Delegates are listed, set them to nil which are suspected.
  2. (Same as my case)Property Object like Textfield can create issue, So set its delegates to nil.
-(void) viewWillDisappear:(BOOL) animated{


[super viewWillDisappear:animated];


if ([self isMovingFromParentViewController]){


self.countryTextField.delegate = nil;


self.stateTextField.delegate = nil;


}


}