标签：
在iOS开发过程中，我们经常会碰到莫名其妙的crash，然后我们又很难定位到。
Debug版本：当我们遇到EXC_BAD_ACCESS crash错误，很有可能是由于我们引用的对象被释放，或者方法不存在，无法调用，这是由于内存操作错误引起的crash。当无法定位错误时，我们引入NSZombieEnabled模式。设置了NSZombieEnabled后，一个对象销毁时会被转化为 _NSZombie，设置NSZombieEnabled后，当你向一个已经释放的对象发送消息，这个对象就不会向之前那样Crash或者产生 一个难以理解的行为，而是放出一个错误消息，然后以一种可预测的可以产生debug断点的方式消失， 因此我们就可以找到具体或者大概是哪 个对象被错误的释放了。在XCODE 中设置NSZombieEnabled模式。点击菜单栏Product->Scheme->Edit Scheme->run->Argument->Environment variables ->+ 添加NSZombieEnabled 设为YES 重新运行。
ps：在应用发布时，记得去掉这一选项。
当我们遇到SIGNAL SIGABRT等错误时候，我们可以使用断点，断点可以分为条件断点及异常断点。断点的作用非常重要，它能够帮我们查看应用程序在给定时间点上的所在位置。
条件断点，顾名思义是指只会在特定条件下触发的断点：
异常断点。当我们遇到异常情况crash的时候，系统一般都会自动指向主方法中。当我们添加了异常断点后，就会再引发问题的地方中断。
Release 版本：程序的异常当我们处于调试阶段，通过上面方法一般都能过定位到错误。那当我们用发布app store版本或者分发版本 出现异常闪退的时候应该怎么定位错误呢？
大家在项目中一般都会加入log日志，我使用的是友盟的错误日志。当用户使用我们的应用crash时，友盟日志会收集这些错误信息，这样我们就可以通过dysm文件去定位到错误位置。
dysm文件是我们编译后会自动生成的，它是保存16进制函数地址映射信息的中转文件，我们调试的symbol 都在这文件中。这个文件很重要，我们每次发布版本都会保存对应.xcarchive文件。有了这个文件我们就可以在发布版中定位用户使用奔溃时的信息，而不需要通过该用户的设备log信息。那究竟应该怎么通过错误信息去定位呢？
下面介绍我使用umeng的错误日志定位错误：
one step 我们打开友盟的错误日志
图中蓝色标记的地址就是出错的函数内存地址。dsym uuId 我们需要找到我们对应的.archives 的文件
dsym uuid : dwarfdumop --uuid xx.app.dSYM
app uuid :dwarfdump --uuid xx.app/xx
和错误文件中uuid 把.app 文件和dYSM 文件放到同一目录 一致我们就可以查询了：
xcrun atos -arch armv7 -o Wherecom.app/Wherecom 0x2a32f 亦可以用dwarfdump 命令查询
这样我们就可以定位到可能引起的错误函数名了。
网上也有热心的网友就这些命令写成了Mac工具附上下载地址， 但是还是建议大家常用命令 熟悉这些常见的命令.
http://download.csdn.net/download/marujunyy/7718089
iOS Debug 和 release(hoc 及App Store)版本Crash错误总结
标签：
原文地址：http://www.cnblogs.com/simple-life-no1/p/4184768.html
