Ocbective-c中的Thread signal:SIGABRT 以及EXC_BAD_ACCESS问题

平常我们写程序的时候经常会遇到这样的问题。program received signal:SIGABRT 以及EXC_BAD_ACCESS


1.SIGABRT 一般是过度release 或者 发送 unrecogized selector导致。


2.EXC_BAD_ACCESS 是访问已被释放的内存导致。


查了下StackOverflow。


SIGABRT is raised by the abort(3) function. It's impossible to tell exactly what's going on in your program without more information, but the most common reasons that abort() gets called are:

Your sending a message to an Objective-C object that doesn't support/implement that message. This results in the dreaded "unrecognized selector sent to instance" error.（你发送给对象一个它并不支持或者是没实现的消息，这导致可怕的 "unrecognized selector sent to instance" 错误）

You have a failed assertion somewhere. In non-debug builds that define the macro NDEBUG, the standard library macro assert(3) calls abort() when the assertion fails.（某个地方你做了个错误的判断）

You have some memory stomping/allocation error. When malloc/free detect a corrupted heap, the may call abort() (see, e.g. this question)

You're throwing an uncaught exception (either a C++ exception or an Objective-C exception)（内存分配出错，内存泄露，会调用abort()）

In almost all cases, the debug console will give you a little more information about what's causingabort() to be called, so always take a look there.


（多数情况下，调试控制台会给你更多的信息关于导致了abort的原因。所以仔细看）。 


3.SIGABRT是处于程序控制状态下的crash，SIGABRT引起的crash是因为系统发现了应用程序正在做一些系统不希望它去做的事情(Exception)。


.一般情况下，当SIGABRT发生的时候，会现实如下的bug信息：
它并不能精确的定位到crash发生在哪个源文件哪行代码中。为了精确的定位，我们可以使用Exception Breakpoint在Exception发生的时候暂停程序。


4. EXC_BAD_ACCESS意味着你的程序在内存管理方面有bug。与SIGABRT不同，发生EXC_BAD_ACCESS错误时，在控制台里你不会得到一个错误的信息，但是你可以通过一些设置得到这些错误信息并进一步定位内存错误发生的位置。

注意：当你把选项Zombie Objects打开的时候，你的应用程序永远不会再释放(dealloc)内存，会导致不停的内存泄漏并最终在某一时刻run out of free memory，所以不要一直开着Zombie Objects选项，只有当你定位EXC_BAD_ACCESS错误的时候打开它，当bug解决掉之后，立刻关闭它。