2018-01-09 11:26:05 CC1991_ 阅读数 2422

       项目开发过程中,使用了友盟统计,就能在友盟给出的错误信息统计中,能比较方便的找出客户端异常的信息,但是很多像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 这类错误信息,如下图所示:


        遇到这种问题的话,如果通过 objectAtIndex 去检索错误的地方,那将会是一个巨大的工作量,那么怎么办才能减轻工作量呢,那就是下面要介绍的情况了。

一、dSYM 文件

       Xcode编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<电脑用户名>/Library/Developer/Xcode/Archives 目录下,对于每一个发布版本我们都很有必要保存对应的 Archives 文件

二、dSYM 文件的作用

       当我们应用程序release 模式打包或上线后,不会像在Xcode中那样直观的看到用崩溃的错误,这个时候就需要分析 crash report 文件了,iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址,通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件,这样就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。但是前提是我们需要有软件版本对应的 dSYM 文件,这也是为什么很有必要保存每个发布版本的 Archives 文件了。

三、如何把文件一一对应

       每一个 xxx.app 和 xxx.app.dSYM 文件都有对应的 UUID,crash文件也有自己的UUID,只要这三个文件的UUID一致,我们就可以通过它们解析出正确的错误函数信息了。
       1.查看 xxx.app 文件的 UUID,terminal 中输入命令 :dwarfdump --uuid xxx.app/xxx (xxx是你的项目名称)
       2.查看 xxx.app.dSYM 文件的 UUID ,在terminal中输入命令:dwarfdump --uuid xxx.app.dSYM 
       3.crash 文件内第一行 Incident Identifier 就是该crash文件的 UUID。

四、dSYM文件分析工具的使用

       1.将打包发布程序时的xcarchive文件,拖入到软件窗口内的任意位置(这里支持多个文件同时拖入,特别注意:文件名不要包含空格)
       2.选中任意一个版本的xcarchive文件,右边会列出该xcarchive文件支持的CPU类型,选中错误对应的CPU类型。
       3.对比错误给出的UUID和工具界面中给出的UUID是否一致。
       4.将错误地址输入工具的文本框中,点击分析。



       尤其是上架应用的时候,有些时候苹果反馈的信息里面也会给具体的错误日志,你可以通过dSYM工具直接可以找到具体报错位置,百试百灵。如果你觉得我写的内容对你有帮助请点赞,如果想和我更进一步交流探讨,也可以关注我的微信公众号,那里面同样有更多使用的方法技巧等着你!







2018-04-25 16:30:43 MinggeQingchun 阅读数 414

来到新公司后,前段时间就一直在忙,前不久 项目 终于成功发布上线了,最近就在给项目做优化,并排除一些线上软件的 bug,因为项目中使用了友盟统计,所以在友盟给出的错误信息统计中能比较方便的找出客户端异常的信息,可是很多像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 这类错误信息,如下图所示:

012.png

遇到这种问题如果通过 objectAtIndex 去检索错误的地方那将会是一个巨大的工作量。

dSYM 文件

什么是 dSYM 文件

Xcode编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下,对于每一个发布版本我们都很有必要保存对应的 Archives 文件 ( AUTOMATICALLY SAVE THE DSYM FILES 这篇文章介绍了通过脚本每次编译后都自动保存 dSYM 文件)。

dSYM 文件有什么作用

当我们软件 release 模式打包或上线后,不会像我们在 Xcode 中那样直观的看到用崩溃的错误,这个时候我们就需要分析 crash report 文件了,iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址,通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件,这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是我们需要有软件版本对应的 dSYM 文件,这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

如何将文件一一对应

每一个 xx.app 和 xx.app.dSYM 文件都有对应的 UUID,crash 文件也有自己的 UUID,只要这三个文件的 UUID 一致,我们就可以通过他们解析出正确的错误函数信息了。

1.查看 xx.app 文件的 UUID,terminal 中输入命令 :

dwarfdump --uuid xx.app/xx (xx代表你的项目名)

2.查看 xx.app.dSYM 文件的 UUID ,在 terminal 中输入命令:

dwarfdump --uuid xx.app.dSYM 

3.crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。

dSYM工具

于是我抽了几个小时的时间将这些命令封装到一个应用中,也为以后解决bug提供了便利。

使用步骤:

1.将打包发布软件时的xcarchive文件拖入软件窗口内的任意位置(支持多个文件同时拖入,注意:文件名不要包含空格)

2.选中任意一个版本的xcarchive文件,右边会列出该xcarchive文件支持的CPU类型,选中错误对应的CPU类型。

3.对比错误给出的UUID和工具界面中给出的UUID是否一致。
4.将错误地址输入工具的文本框中,点击分析。
Mac app下载地址  项目源码地址

002.jpg

2017-02-03 16:34:37 opentogether 阅读数 297

来到新公司后,前段时间就一直在忙,前不久 项目 终于成功发布上线了,最近就在给项目做优化,并排除一些线上软件的 bug,因为项目中使用了友盟统计,所以在友盟给出的错误信息统计中能比较方便的找出客户端异常的信息,可是很多像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 这类错误信息,如下图所示:

012.png

遇到这种问题如果通过 objectAtIndex 去检索错误的地方那将会是一个巨大的工作量。

dSYM 文件

什么是 dSYM 文件

Xcode编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下,对于每一个发布版本我们都很有必要保存对应的 Archives 文件 ( AUTOMATICALLY SAVE THE DSYM FILES 这篇文章介绍了通过脚本每次编译后都自动保存 dSYM 文件)。

dSYM 文件有什么作用

当我们软件 release 模式打包或上线后,不会像我们在 Xcode 中那样直观的看到用崩溃的错误,这个时候我们就需要分析 crash report 文件了,iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址,通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件,这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是我们需要有软件版本对应的 dSYM 文件,这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

如何将文件一一对应

每一个 xx.app 和 xx.app.dSYM 文件都有对应的 UUID,crash 文件也有自己的 UUID,只要这三个文件的 UUID 一致,我们就可以通过他们解析出正确的错误函数信息了。

1.查看 xx.app 文件的 UUID,terminal 中输入命令 :

dwarfdump --uuid xx.app/xx (xx代表你的项目名)

2.查看 xx.app.dSYM 文件的 UUID ,在 terminal 中输入命令:

dwarfdump --uuid xx.app.dSYM 

3.crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。

dSYM工具

于是我抽了几个小时的时间将这些命令封装到一个应用中,也为以后解决bug提供了便利。

使用步骤:

1.将打包发布软件时的xcarchive文件拖入软件窗口内的任意位置(支持多个文件同时拖入,注意:文件名不要包含空格)

2.选中任意一个版本的xcarchive文件,右边会列出该xcarchive文件支持的CPU类型,选中错误对应的CPU类型。

3.对比错误给出的UUID和工具界面中给出的UUID是否一致。
4.将错误地址输入工具的文本框中,点击分析。
Mac app下载地址  项目源码地址

002.jpg

2016-12-01 20:44:46 Sir_Coding 阅读数 5068
项目中集成了友盟统计,自然Crash日志已经在友盟的统计之中,点击错误分析可以看到相关的错误列表,以及简单的crash日志。

如果想看详细的crash详情则需要使用友盟的错误分析工具:umcrashtool

  • 下载友盟Crash分析工具

  • 在桌面或者任何位置创建一个文件夹,取名:umcrash。下载成功以后,将工具放到文件夹中

  • 打开友盟,点击错误列表,下载你需要查看的版本相关日期内的crash日志。下载成功以后,将文件放到文件夹中

导出Crash日志文件1

导出Crash日志文件2

导出Crash日志文件3

umcrash文件夹

  • 打开终端,跳到umcrash文件夹目录下,命令行: cd 文件夹目录
  • 执行当前命令:
    命令行: ./umcrashtool 【一个空格】/Your错误列表.csv文件目录
    栗 子: ./umcrashtool /Users/DanielYao/Downloads/umcrash/appname_错误分析20161130错误列表_112142.csv

这里写图片描述

  • 如果你的dsym文件在解析的目录下,输入上一句命令行后,Enter 后就会显示出详细的crsh日志

  • 如果你的dsym文件不存在或者有其他的问题,根据提示修改。如果根据目录去找,有时候会发现dsym文件不存在,很大可能是因为Xcode设置原因,会在下面的图示中指明。(Please move dsym file:”” to ~ Xcode/.)
    出现情况如下:
    移动dsym

  • dsym找不到 原因之一 – Xcode设置问题,解决办法如图⬇️

    Xcode设置

  • 如果这篇没解决你的问题,转移到这篇:
    友盟crash日志分析2

2018-04-25 14:21:23 MinggeQingchun 阅读数 1158
首先,确保在release(Ad Hoc或者App Store)一个版本时,保存了对应的xxx.app和xxx.dSYM文件。

其次,验证xxx.crash、xxx.app和xxx.dSYM三者的uuid是否一致。

验证方法:

1)查看xxx.app的uuid。

[plain] view plain copy
  1. $ dwarfdump --uuid mobileguard.app/mobileguard  

2)查看xxx.dSYM的uuid。

[plain] view plain copy
  1. $ dwarfdump --uuid mobileguard.app.dSYM/Contents/Resources/DWARF/mobileguard  

3)xxx.crash。

Note:

在这之前,需要找到对应的app和dSYM文件。这两个文件是在后缀为.archive的文件中,在我的机器(Mac OS 10.9.1,Xcode5.0.2)上,.archive文件在“/Users/mikelin/Library/Developer/Xcode/Archives/”文件夹下对应的日期文件夹中,也可以从Xcode > Organizer > Archive 下找到对应的Archive包。

确保三者uuid一致以后,用symbolicatecrash工具生成易读的日志信息。

先准备环境:

1)链接symbollicatecrash到/usr/bin/中,就可以直接使用sybollicatecrash命令。

[plain] view plain copy
  1. $ ln -s  /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash /usr/bin/symbolicatecrash   

2)设置xcode DEVELOPER_DIR。

[plain] view plain copy
  1. export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"  

然后执行命令:

[plain] view plain copy
  1. symbolicatecrash m.crash mobileguard.app.dSYM > n.crash  

接下来是最重要的环节:

[plain] view plain copy
  1. $ xcrun atos -arch armv7 -o mobileguard.app/mobileguard 0x00037000  

下面这个是我机器上看到的结果:

[plain] view plain copy
  1. $ xcrun atos -arch armv7 -o mobileguard.app/mobileguard 0x00037000  
  2. -[MobileLocationViewCtrl viewDidLoad] (in mobileguard) (MobileLocationViewCtrl.m:56)  
没有更多推荐了,返回首页