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

       项目开发过程中,使用了友盟统计,就能在友盟给出的错误信息统计中,能比较方便的找出客户端异常的信息,但是很多像数组越界却只给出了 *** -[__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 阅读数 440

来到新公司后,前段时间就一直在忙,前不久 项目 终于成功发布上线了,最近就在给项目做优化,并排除一些线上软件的 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

2018-03-16 17:57:19 XuanTong520 阅读数 2993

iOS通过dSYM文件分析crash日志

平常在开发的过程中,遇到到了Crash可以很容易的通过Xcode去定位Crash的位置,但是当我们的App发布以后,遇到闪退就不可以通过Xcode去调试了。当然现在也有很多产品可以在线分析,例如腾讯的bugly与友盟的错误分析。这些分析工具的最基本的地方还是通过dSYM去分析Crash日志,符号化Crash日志。

准备工作

分析崩溃日志需要三个东西:1、crash文件 2、symbolicatecrash文件 3、dYSM文件。我们拿到这个三个文件后,一般新建一个文件夹,把这三个文件放一起。至于crash文件和dYSM文件在哪里找,出门左转,度娘谢谢。

1、如何查找symbolicatecrash文件?

打开终端,输入 find /Applications/Xcode.app -name symbolicatecrash -type f,我用的是Xcode9,返回的结果如下:

如果是iPhone设备,选择红框中的路径,这样就可以找到symbolicatecrash文件

2、检测dYSM文件和crash文件是否对应
从终端进入到刚刚创建的crash文件中,输入dwarfdump --uuid xxx.app.dSYM(xxx是工程名)。如果输出的uuid和crash文件中的一致,则可以解析出正确的crash文件。crash文件中的uuid位于Binary Images中的第一行尖括号内。

3、解析crash文件
在终端中输入./symbolicatecrash crash.crash xxx.app.dSYM >crashLog.text,(xxx是工程名)。这样就可以在你的文件中看到解析后的崩溃文件。

注意,一般情况下,第一次使用symbolicatecrash会产生一个error,如下的错误信息
Error: "DEVELOPER_DIR" is not defined at /usr/local/bin/symbolicatecrash line 53.

解决办法是输入export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer

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

来到新公司后,前段时间就一直在忙,前不久 项目 终于成功发布上线了,最近就在给项目做优化,并排除一些线上软件的 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-07-13 15:10:56 koocui 阅读数 225

命令行工具解析Crash文件&&dSYM文件进行符号化

话说:

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

获取崩溃信息方式

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

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

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

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

     4,使用苹果提供的Crash崩溃收集服务。

收集崩溃信息

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

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

// 将系统提供的获取崩溃信息函数写在这个方法中,以保证在程序开始运行就具有获取崩溃信息的功能 
 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // 将下面C函数的函数地址当做参数 NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler); return YES; } // 设置一个C函数,用来接收崩溃信息

void UncaughtExceptionHandler(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文件,其他电脑生成的文件可能会导致分析不准确的问题。





当程序崩溃的时候,我们可以获得到崩溃的错误堆栈,但是这个错误堆栈都是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文件了。





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





进行解析的工作

开启命令行工具,进入崩溃文件夹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文件,这个文件中就是崩溃详细信息。图中红色标注的部分就是我们代码崩溃的部分。





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

  • 内存访问错误(不是野指针错误)
  • 低内存,当程序内存使用过多会造成系统低内存的问题,系统会将程序内存回收
  • 因为某种原因触发看门狗机制

通过Xcode查看设备崩溃信息

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





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

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




原文链接:http://www.jianshu.com/p/0b6f5148dab8

没有更多推荐了,返回首页