博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Xcode分析CrashLog的方法
阅读量:4200 次
发布时间:2019-05-26

本文共 788 字,大约阅读时间需要 2 分钟。

Bug是永远伴随着程序员们的东西,各种各样的情况造成程序crash掉也是家常便饭。Windows下的很多大型软件在崩溃的时候,都会弹出提示框,询问用户是否将crash的信息发送到软件厂商,以供软件开发商debug。App store中的软件也有这个功能,用户在使用软件的时候,如果程序崩溃,错误信息会发送到Apple的服务器中,软件的开发者们可以很方便在后台获得自己程序的crash log,供自己调试。

但随之而来的问题是,我们收到的程序崩溃调试信息多半是汇编语言一样的堆栈代码,同时这些信息并不是在我们debug的时候产生,所以看到这一串crash log的天书,常常无可奈何。Xcode很好的解决了这一问题,它所提供的Orgainzer分析器加上symbolicatecrash,可以分析二进制文件以及源代码和crashlog之间的连接,直接找出源程序中出错的代码行。方法网上到处是,本文不讨论。

但是如果使用symbolicatecrash无法定位到出错的代码行的话,怎么整呢?有一个办法,如下:

首先查看crash log中的崩溃线程,假如是这样的:

Thread 0 Crashed:

0   libobjc.A.dylib               0x00003ec0 objc_msgSend + 24
1   MyApp               0x000036d2 0×1000 + 9938

我们得到了用户发生崩溃情况的内存地址:0x000036d2

然后回到我们应用程序的build目录,目录下一定要包含MyApp.app 和MyApp.app.dSYM两个文件。

在控制台使用dwarfdump命令,解析出内存地址,如: 

dwarfdump --lookup 0x000036d2 -arch armv6 MyApp.app.dSYM

输出信息如下:

直接定位到代码的出错行,Cool!

from:

转载地址:http://ozbli.baihongyu.com/

你可能感兴趣的文章
数据库基础问答Q&A
查看>>
DeepCopy
查看>>
R语言问题——连接数据库乱码问题解决方案
查看>>
json读取+对象转换+csv读写
查看>>
加密算法比较3DES AES RSA ECC MD5 SHA1等
查看>>
[Python]Anaconda(python数据分析工具箱版)安装
查看>>
CentOS安装glibc-2.14
查看>>
Hadoop FS Shell Command
查看>>
Eclipse版本查看
查看>>
Linux下安装MySql(多实例+主备)
查看>>
检测远程端口是否打开
查看>>
curl operate elasticsearch
查看>>
kibana做图表无法选取需要选的字段
查看>>
ELK setup guide
查看>>
Splunk setup guide
查看>>
hive性能优化
查看>>
Spark运行任务
查看>>
Java - Elasticsearch RestFul连接搜索查询
查看>>
Java - Elasticsearch查询类型
查看>>
WebSocket vs REST
查看>>