跟踪EXC_BAD_ACCESS没有NSZombie？ [英] Tracking down EXC_BAD_ACCESS without NSZombie?

问题描述

我花了两天时间，我仍然找不到崩溃的原因。

我知道它与尝试访问已被释放的对象有关，但是我不知道哪个访问或哪个对象。

每当我google试图找到EXC_BAD_ACCESS的源时，人们建议使用NSZombies。问题是当我启用僵尸（在xcode通过环境变量或仪器通过ObjectAlloc属性）程序不会崩溃，它通常做的地方，僵尸不报告任何东西（没有什么显示在日志中，没有任何标记仪器）。有没有什么我失踪与NSZombie？

我已经尝试利用xcode的调试器和仪器中的ObjectAlloc的一些信息，但所有的信息都是非常隐蔽的，并不真正帮助我。

我已经设置调试器停止在objective-c异常。当它这样做时，这是显示的调用堆栈：

  0 objc_msgSend 
 1？ 
 2  -  [UITableViewCell removeFromSuperView] 
 3  -  [UIView dealloc] 
 ... etc ... 
  

首先，什么是'1 ??'的处理？问号是什么意思？其次我怎么知道我的代码在哪里调用？所有的操作都是一般的（例如UIView dealloc，但是UIView？在哪里？）。

同样当异常发生时它指向汇编代码，除非我花了几个小时试图弄清楚代码的作用，否则不要让我任何好处。我知道一些装配，但有是一个更好的方法...对不对？

有什么方法可以得到有意义的信息，在异常发生之前在我的代码中运行的最后一行是什么？

我尝试了一些NSLogs和断点，但它不能帮助我，因为崩溃发生之后，我从导航控制器弹出视图控制器。到处我放置断点的断点都达到了（我不能找到一个点来突破后崩溃）。只有当我继续在调试器中发生异常时。这就像崩溃发生在我的代码之外，所以我不知道在哪里得到一个句柄。

我看过我的代码，坚持所有的内存管理规则（至少在我最好的知识）。我相信这是一个非常微妙的东西，但我似乎找不到它。

如果任何人有任何想法如何找到这种错误没有NSZombie请分享。 p>

谢谢。

解决方案

我有一个自定义表单元格类，其中我在dealloc方法（而不是最后）中首先调用[super dealloc]。我想我匆忙写这个类，并没有真正想到它。我猜在孩子需要释放的父母发布了什么？

所以我没有真正的答案，我自己的问题，但基本上我发现问题使用特殊代码跟踪和各种调试技术（断点，NSLogs，试图解密隐藏的堆栈跟踪等）的组合。

实际上，帮助我的主要策略是一点一点地注释掉代码，直到我把问题区域变得简单，同时仍然保持崩溃原封不动。这让我意识到问题不是我认为它会是，但在一个更微妙的区域（例如在这种情况下的次要类的dealloc方法）。

我希望这可以帮助别人。我会离开这个问题没有回答有一点，有人有一个更彻底的调试策略，而不依赖于NSZombies。如果有人可以澄清这两个问号在堆栈跟踪中意味着什么是有用的。

I've spent two days on this and I still can't find the cause of the crash.

I know it has something to do with trying to access an object that has been freed but I don't know which access or which object.

Whenever I google trying to find the source of EXC_BAD_ACCESS people suggest using NSZombies. The problem is when I enable zombies (either in xcode via environment variable or in instruments via ObjectAlloc properties) the program doesn't crash where it usually does and the zombies don't report anything (nothing shows up in logs and nothing is flagged in instruments). Is there something I'm missing with NSZombie?

I've tried utilizing some information from xcode's debugger and from ObjectAlloc in instruments but all the information is very cryptic and doesn't really help me.

I've set the debugger to stop on objective-c exceptions. When it does it this is the call stack shown:

0 objc_msgSend
1 ??
2 -[UITableViewCell removeFromSuperView]
3 -[UIView dealloc]
... etc ...

First of all, what's the deal with '1 ??' ? What do the question marks mean? Second of all how can I know where this was called in my code? All the operations stated are too generic (eg UIView dealloc, but which UIView? And where?).

Also when the exception occurs it points to assembly code which again, doesn't do me any good unless I was to spend hours trying to figure out what the code does. I know some assembly but there has to be a better way... right?

Is there any way I can get meaningful information as to what was the last line that ran in my code before the exception occurred?

I've tried sprinkling some NSLogs and breakpoints around but it doesn't help me much because the crash happens after I pop a view controller from a navigation controller. Everywhere I place breakpoints the breakpoints are reached fine (I can't find a point to break after the crash). It's only when I 'continue' in the debugger that the exception occurs. It's as if the crash happens outside of my code so I have no idea where to get a handle on it.

I've looked through my code and double checked that I adhere to all the memory management rules (at least to the best of my knowledge). I'm sure it's something very subtle but I can't seem to find it.

If anyone has any ideas how to find such bugs without NSZombie please share.

Thanks.

解决方案

Well I found the problem. I had a custom table cell class in which I called [super dealloc] first in the dealloc method (rather than last). I guess I wrote this class in a hurry and didn't really think about it. I'm guessing something got released in the parent that the child needed for releasing?

So I don't have a real answer to my own question but basically I found the problem using a combination of ad-hoc code tracing and various debugging techniques (breakpoints, NSLogs, trying to decypher cryptic stack trace,etc).

Actually the main strategy that helped me was commenting out code bit by bit until I stripped down the problem area into as simple as it gets while still keeping the crash intact. This let me realize the problem wasn't where I thought it would be but in a more subtle area (eg in the dealloc method of a secondary class in this case).

I hope this can sort of help someone out. I'll leave this question unanswered for a bit incase someone has a more thorough debugging strategy without relying on NSZombies. Also if someone can clarify what those two question marks mean in the stack trace that would be helpful.

这篇关于跟踪EXC_BAD_ACCESS没有NSZombie？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！