首页 > 代码库 > iOS Debug 和 release(hoc 及App Store)版本Crash错误总结

iOS Debug 和 release(hoc 及App Store)版本Crash错误总结

在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错误总结