IOS crash处理

在调试程序的时候，总是碰到crash的bug，而且一追踪就是一些汇编的代码，让人特别疑惑。下面总结一些crash调试几种的方法。

基本上有错误分为以下几种类型：

signal(SIGABRT, MySignalHandler);

signal(SIGILL, MySignalHandler);

signal(SIGSEGV, MySignalHandler);

signal(SIGFPE, MySignalHandler);

signal(SIGBUS, MySignalHandler);

signal(SIGPIPE, MySignalHandler);

SIGABRT和EXC_BAD_ACCESS较为特殊，算是比较好跟进。

SIGABRT是系统报错，在memery warning之后,系统会把程序强制退出，报的就是这个错误。

EXC_BAD_ACCESS 大多数时候是内存提前释放而引起的问题，或者访问的方法不存在引起的。

SIGSEGV 使用全局断点解决。

追踪程序的调用stacktrace的方法，跟踪问题：

一般出错了之后出现的常见界面，再熟悉不过了。。

切换到breakpoint界面，拖动底端的slider按钮，显示调用堆栈

设置全局异常断点（SIGSEGV ）

有时候我们看不懂堆栈里的汇编代码，最后能够定位到出错的地方。那就用到下面的内容了：添加Symbol breakpoint Exception breakpoint

一、Exception breakpoint全局断点
这个比较常用就不详细叙述了
二、Symbolic breakpoint
系统抛出异常处设置断点
有时候我们的程序不知道跑到哪个地方就 crash 了，而 crash 又很难重现。保守的做法是在系统抛出异常之前设置断点，具体来说是在 objc_exception_throw处设置断点。
这样在 Debug 模式下，如果程序即将抛出异常，就能在抛出异常处中断了。

添加完成之后在 Symbol 一栏输入：objc_exception_throw，然后点击
done，完成。

添加完成只两个断点之后，程序中很多异常也可以捕获了，直接定位到出问题的位置。

三.设置为NSZombieEnabled模式

四. OC的异常处理机制Exception

Object-C语言的异常处理符号和C++、JAVA相似。再加上使用NSException，NSError或者自定义的类，你可以在你的应用程序里添加强大的错误处理机制。
异常处理机制是由这个四个关键字支持的：@try，@catch，@thorw，@finally。当代码有可能出现异常时，我们把他放到@try语句块中。@catch()块包含了处理@try块里的抛出的异常的逻辑。无论异常是否发生，@finally块里面的语句都会执行。如果直接使用@throw块来抛出异常，这个异常本质上是一个OC的对象。咱们可以使用NSException对象，但是不局限于他们。

@try { 

} @catch (NSException *exception) {

NSLog(@”main: Caught %@: %@”, [exception name], [exception reason]);

} @finally {

}