dSYM崩溃日志分析(转)

First

相信有很多开发者在项目中加入了友盟统计,其中一个最主要的功能就是查看线上版本统计到的错误。但是当你看到这样的信息时:

dSYM崩溃日志分析(转)_第1张图片

会不会有这样的想法:

这尼玛到底是什么鬼?!!

此时你可能会百度(干得漂亮!),我相信你“闪闪”的双眼肯定会看到这篇文章的:dSYM文件分析工具。具体用法我就不重复了,博主写的很详细,而且这个工具真的真的很好用!

Second

但是,友盟还统计到了这么一堆错误:

dSYM崩溃日志分析(转)_第2张图片

这尼玛又是什么鬼?!!怎么会这么多!

点进去看到是这样的:

dSYM崩溃日志分析(转)_第3张图片

用咱们上面说的工具:

dSYM崩溃日志分析(转)_第4张图片

这、这、这让我怎么玩,还能不能愉快的玩耍了…T_T

当然,这并不只在“Application received signal SIGSEGV (null)”这种情况下才发生,这时怎么办呢?不要捉急,少年请看这里:解析iOS崩溃日志(crash Log)。

Third

上面这两种方法应该就可以解决大部分友盟统计到的错误了,这时你要说了,这两种方法都解决不了的怎么办?少年,此次此刻我要传授你一招江湖失传很久的绝学秘笈:把那些无法解决的错误全部勾选上,然后选择把状态标记为“处理中”,然后再标记为“已修复”,怎么样,骚年,是不是解决了!2333,但是少用为好,原因你懂的。

At last

最后感谢answer-huang和裂云野的博文分享。



【友盟统计报表解读】之错误分析iOS版

错误分析功能说明

1.概述

错误分析是友盟为移动开发者提供的Crash收集和分析工具,帮助开发者监测App在移动设备上的运行状况,及时发现并解决错误,提升App的稳定性。

新版错误分析的主要功能点如下:

(1) 通过友盟后台网站管理错误内容。

您可以按照版本、UUID、操作系统、机型筛选错误; 还可以根据不同的条件为错误添加标签,便于快速分类及查找错误。

(2) 通过友盟错误分析工具定位错误。

您可以在友盟后台网站批量导出错误,并借助命令行工具将错误快速定位到具体的代码行数。

2.详细说明2.1 错误列表页

错误列表中展示的错误摘要的生成规则是,将收集Crash日志通过一定算法聚合后按照UUID拆分的错误的堆栈信息的第一行。

每天展示当日发生的错误,且每天至多展示1000条错误类型。当错误类型超过1000条时,当日错误列表中的数据不再更新。次日恢复。

当错误列表中超过1000条时,请在版本管理中取消不关注的版本;版本取消后,当日不再接收该版本的错误,但不会减少当日已接收的错误数。

2.1.1 筛选

按照您为错误标记的状态来筛选错误

选择至多3个版本,只展示选中版本的数据

通过UUID来搜索错误

通过操作系统或机型来筛选错误

通过自定义标签来筛选错误,同时可添加新标签或删除标签

2.1.2 标记

(1) 添加标记

选中相应的错误 ,可以为其添加多个标签或标记为已修复/未修复。

dSYM崩溃日志分析(转)_第5张图片

为选中的错误添加标签

为选中的错误标记修复状态,便于跟踪错误

(2) 修改或删除标记

如果想修改标签,需进入错误详情页进行修改

dSYM崩溃日志分析(转)_第6张图片

2.1.3 导出

导出当前页面内的全部错误,或导出该页面内勾选的错误

dSYM崩溃日志分析(转)_第7张图片

2.1.4 管理版本(1)查看今日接收的错误数并进行版本管理

dSYM崩溃日志分析(转)_第8张图片

今日错误数展示的是今日收到的全部错误数(聚合后的错误类型数);当今日错误类型超过1000个的限制时,此处的数据不再更新。

选择接收错误信息的版本,当某版本取消选中时,该版本的错误信息将不再继续接收。

(2)选择接收错误的版本

dSYM崩溃日志分析(转)_第9张图片

该版本今日收到的总错误数

展开/收起UUID列表

2.2 错误详情

错误详情页面展示的是错误详细的stacktrace以及其他相关信息。

2.2.1 基本信息

包括错误的首次发生时间、最近一次发生时间、今天发生的次数以及出现的应用版本。

该错误首次发生的时间

该错误最近一次的发生时间

该错误出现的总次数

发生该错误的应用版本

2.2.2 终端概况

终端概况提供了设备,机型和操作系统的联合分布信息,可以点击查看分布详情。

dSYM崩溃日志分析(转)_第10张图片

2.2.3 错误详情

可以修改错误标签,修改错误状态。

dSYM崩溃日志分析(转)_第11张图片

修改错误的标签

修改错误的已修复/未修复状态

2.3 错误分析工具的使用

第一步下载错误分析工具并解压zip得到umcrashtool文件,可将umcrashtool与已下载的xxx.csv文件放入同一目录下。

第二步 在terminal中运行umcrashtool命令,参数为错误分析的.csv文件绝对路径,如下:

sanzhang$ ./umcrashtool [absolutely_path_of_csv_file]

将umcrashtool与错误分析.csv文件放入同一目录下

dSYM崩溃日志分析(转)_第12张图片

第三步 在terminal中运行umcrashtool,提示如下: Usage: umcrashtool [export-file-path],定位后的代码及行数会写入错误分析-symbol.csv文件,与原文件在同一目录下。用工具打开新生成的xxx-symbol.csv文件,便可查看错误发生的源码文件及行数。

注:如果错误分析没有成功,请先确保对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。(对于每一个产品发布时archive操作会将dsym文件存放到~/Library/Developer/Xcode/Archives路径下,因此建议保留该路径下的文件,以便后续用工具分析错误。)

dSYM崩溃日志分析(转)_第13张图片

更详细的使用教程见这里。

3. FAQ

Q:错误类型超过1000个的限制该如何处理?

A:每天至多展示1000个错误,当超过1000个的限制后,该日的数据不再更新。次日恢复。

当超过限制后,您可以在版本管理中选择接收错误的版本/UUID,对不关注的版本/UUID取消选中。取消选中的版本/UUID不再接收错误。

选择您关注的版本/UUID接收错误,关闭不关注的版本,会降低次日错误超过1000的情况。

Q:为什么有些错误无法通过友盟提供的工具定位 ?

A:因为您使用的SDK版本过低。 必须使用v2.1.3以后的SDK才能正确的定位Crash log。

Q:使用umcrashtool为什么没有正确的翻译出错误 ?

A:您需要确保dSYM文件存放在/Users/xx/Library/Developer/Xcode/或者它的子目录下,路径中不要出现空字符。

Q:为什么生成的csv文件打开有乱码?

A:csv文件我们使用的UTF8编码格式,需要选用相应的格式打开,在Mac平台可以用系统自带的Numbers或免费软件LibreOffice打开。目前的Microsoft Office for Mac 打开会有乱码的问题。

Q:使用umcrashtool为什么没有正确的翻译出错误?

A:首先请确保dSYM文件存放在 ~/Library/Developer/Xcode/或者它的子目录下。另外, 目前的错误捕捉工具针对一些系统信号导致的崩溃信息,存在无法解析的情况,最后可能是dsym文件提供的信息量不够,导致部分解析失败。我们的技术人员一直在努力提高能够捕获和分析的崩溃的类型,如果您在这方面有建议,也可以通过邮件[email protected]或友盟开发者社区反馈给我们。






!!!!!命令行工具解析Crash文件,dSYM文件进行符号化序

在日常开发中,app难免会发生崩溃。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。

获取崩溃信息方式

在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟、云测、百度等第三方分析工具,或者自己收集崩溃信息并上传公司服务器。

下面列举一些我们常用的崩溃分析方式:

使用友盟、云测、百度等第三方崩溃统计工具。

自己实现应用内崩溃收集,并上传服务器。

Xcode-Devices中直接查看某个设备的崩溃信息。

使用苹果提供的Crash崩溃收集服务。(少用)

收集崩溃信息

苹果给我们提供了异常处理的类,NSException类。这个类可以创建一个异常对象,也可以通过这个类获取一个异常对象。

这个类中我们最常用的还是一个获取崩溃信息的C函数,我们可以通过这个函数在程序发生异常的时候收集这个异常。

// 将系统提供的获取崩溃信息函数写在这个方法中,以保证在程序开始运行就具有获取崩溃信息的功能- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions {// 将下面C函数的函数地址当做参数NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);returnYES;  }// 设置一个C函数,用来接收崩溃信息voidUncaughtExceptionHandler(NSException*exception){// 可以通过exception对象获取一些崩溃信息,我们就是通过这些崩溃信息来进行解析的,例如下面的symbols数组就是我们的崩溃堆栈。NSArray*symbols = [exception callStackSymbols];NSString*reason = [exception reason];NSString*name = [exception name];  }

我们也可以通过下面方法获取崩溃统计的函数指针:

NSUncaughtExceptionHandler*handler =NSGetUncaughtExceptionHandler();

dSYM 符号集

符号集是我们对ipa文件进行打包之后,和.app文件同级的后缀名为.dSYM的文件,这个文件必须使用Xcode进行打包才有。

每一个.dSYM文件都有一个UUID,和.app文件中的UUID对应,代表着是一个应用。而.dSYM文件中每一条崩溃信息也有一个单独的UUID,用来和程序的UUID进行校对。

我们如果不使用.dSYM文件获取到的崩溃信息都是不准确的。

符号集中存储着文件名、方法名、行号的信息,是和可执行文件的16进制函数地址对应的,通过分析崩溃的.Crash文件可以准确知道具体的崩溃信息。

我们每次Archive一个包之后,都会随之生成一个dSYM文件。每次发布一个版本,我们都需要备份这个文件,以方便以后的调试。进行崩溃信息符号化的时候,必须使用当前应用打包的电脑所生成的dSYM文件,其他电脑生成的文件可能会导致分析不准确的问题。

dSYM崩溃日志分析(转)_第14张图片

Archive.png

当程序崩溃的时候,我们可以获得到崩溃的错误堆栈,但是这个错误堆栈都是0x开头的16进制地址,需要我们使用Xcode自带的symbolicatecrash工具来将.Crash和.dSYM文件进行符号化,就可以得到详细崩溃的信息。

崩溃分析

命令行解析Crash文件

通过Mac自带的命令行工具解析Crash文件需要具备三个文件

symbolicatecrash,Xcode自带的崩溃分析工具,使用这个工具可以更精确的定位崩溃所在的位置,将0x开头的地址替换为响应的代码和具体行数。

我们打包时产生的dSYM文件。

崩溃时产生的Crash文件,例如:*.crash。

我在解析崩溃信息的时候,首先在桌面上建立一个Crash文件夹,然后将.Crash、.dSYM、symbolicatecrash放在这个文件夹中,这样进入这个文件夹下,直接一行命令就解决了。

symbolicatecrash我们可以在下面路径下可以找到,我用的是Xcode7,其他版本Xcode路径不一样,请自行Google。

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

选中archive的版本右击,选择Show in Finder就可以选中archived 文件然后显示包内容,就可以找到dSYM文件了。

dSYM崩溃日志分析(转)_第15张图片

dsym文件位置.png

将.Crash、.dSYM、symbolicatecrash三个文件都放在我们在桌面建立的Crash文件夹中。

dSYM崩溃日志分析(转)_第16张图片

crash.png

进行解析的工作

开启命令行工具,进入崩溃文件夹crash中

cd/Users/自己MacPro上的名字/Desktop/崩溃文件夹crash

使用命令解析Crash文件,*号指的是具体的文件名

./symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash

如果上面命令不成功,使用命令检查一下环境变量

xcode-select -print-path

返回结果:

/Applications/Xcode.app/Contents/Developer/

如果不是上面的结果,需要使用下面命令设置一下导出的环境变量,然后重复上面解析的操作。(这一步很重要)

export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

解析完成后会生成一个新的.Crash文件,这个文件中就是崩溃详细信息。图中红色标注的部分就是我们代码崩溃的部分。

dSYM崩溃日志分析(转)_第17张图片

result.png

注意,以下情况不会有崩溃信息产生:

内存访问错误(不是野指针错误)

低内存,当程序内存使用过多会造成系统低内存的问题,系统会将程序内存回收

因为某种原因触发看门狗机制

通过Xcode查看设备崩溃信息

除了上面的系统分析工具来进行分析,如果是我们自己直接使用手机连接崩溃或者崩溃之后连接手机,选择window-> devices -> 选择自己的手机 -> view device logs 就可以查看我们的崩溃信息了。

dSYM崩溃日志分析(转)_第18张图片

deviceLog.png

只要手机上的应用是这台电脑安装打包的,这样的崩溃信息系统已经为我们符号化好了,我们只需要进去之后等一会就行(不要相信这里面的进度刷新,并不准确),如果还是没有符号化完毕 ,我们选择文件,然后右击选择Re-Sysbomlicate就可以。

如果是使用其他电脑进行的打包,我们可以在这里面将Crash文件导出,自己通过命令行的方式进行解析。

日记本

© 著作权归作者所有

举报文章

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

打赏支持

喜欢

17

更多分享6条评论只看作者

按时间正序按时间倒序按喜欢排序EmptyWalker

2楼 · 2016.05.18 08:43

请问博主,你的crash文件指的是什么文件,对于友盟统计的错误来说,我要怎么获取crash文件呢?谢谢

回复

天清水蓝:@EmptyWalker同问,我用的云测统计,云测里面连内存地址都没有。。。更坑!想知道上线的应用.crash文件怎么获取

2016.08.02 20:10回复

Somerr态:同问,从友盟怎么获取crash文件?

2016.09.10 17:01回复

添加新评论

rensheng

3楼 · 2016.09.08 17:46

Mark 大神 膜拜啊

回复

Clemo

4楼 · 2016.11.18 14:26

现在xcode获取的crash文件好像是自动符号化了的吧?

回复XVXVXXX

5楼 · 2016.12.06 17:07

symbolicatecrash我们可以在下面路径下可以找到,我用的是Xcode7,其他版本Xcode路径不一样,请自行Google。

find /Applications/Xcode.app -name symbolicatecrash -type f

你可能感兴趣的:(dSYM崩溃日志分析(转))