iOS通过dSYM文件分析crash

http://blog.csdn.net/hjy_x/article/details/20929095

重点是dwarfdump --uuid命令

我们在ios开发中会碰到的很多crash问题,如果Debug调试模式的话,我们可以往往很容易的根据log的输出定位到导致crash的原因,但对于已经上线的应用,或者是release环境包导致的crash,我们就需要一些特殊的手段来通过crash log进行分析定位了。

通过参考网上的一些资料,总结了一下,下面介绍一下通过dSYM文件以及crash log分析定位的方法。

1.导出crash log

通过Xcode的Organizer查看某台iphone设备的DeviceLog,选择需要的crash log,导出XXX.crash文件。

2.找到对应的app文件

找到当前iphone设备上安装的ipa文件,更改文件后缀名为zip,解压后得到Payload文件夹,你需要的app文件就在其中了。

3.找到对应build版本的dSYM文件

dSYM文件是iOS编译后保存16进制函数地址映射信息的文件,每次应用程序build后,都会生成对应的xxx.app, xxx.app.dSYM文件。

4.确定dSYM、app以及crash文件的关系

每一个xx.app, xxx.app.dSYM文件都拥有相应的uuid,crash文件也有uuid,只有三者uuid一至才表明之三者可以解析出正确的日志文件。
查看xx.app文件的uuid的方法,在terminal中输入命令:

dwarfdump --uuid xxx.app/xxx (xxx工程名)

查看xx.app.dSYM文件的uuid的方法,在terminal中输入命令:

dwarfdump --uuid xxx.app.dSYM (xxx工程名)

而.crash的uuid位于,crash日志中的Binary Images:中的第一行尖括号内。如:

armv7 <8bdeaf1a0b233ac199728c2a0ebb4165>

将对应的xxx.app.dSYM文件以及xxx.app文件以及xxx.crash文件拷贝到同一文件夹中,如:~/Desktop/DebugLog。

5.通过symbolicatecrash分析crash文件

Xcode有自带的symbolicatecrash工具,可以通过dSYM文件将crash文件中的16进制地址转换成可读的函数地址。symbolicatecrash工具位于:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash(Xcode 4.5)
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash(Xcode 5.0)

该文件是隐藏文件,可以通过如下命令查找并拷贝到系统目录下,并建立快捷方式。

1)打开终端,进入到symbolicatecrash工具所在的文件夹目录

cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/

2)查找确认是否存在symbolicatecrash

ls -al | grep symbolicatecrash

3)将symbolicatecrash工具拷贝到/usr/bin目录下

sudo cp symbolicatecrash /usr/bin/symbolicatecrash

4)设置DEVELOPER_DIR系统变量

cd ~/

vi .bash_profile

并输入如下内容
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"

保存并退出

source .bash_profile

5)重启终端,确认是否已正确设置DEVELOPER_DIR系统变量

echo $DEVELOPER_DIR

查看输出结果是否为/Applications/Xcode.app/Contents/Developer

6)查看PATH系统变量是否存在如下路径/usr/bin

echo $PATH

7)如果PATH不存在如下路径/usr/bin,可在~/.bash_profile中添加如下代码

export PATH="/usr/bin:$PATH"

保存并退出

source .bash_profile

8)上述准备工作完成后,进入dSYM和crash文件对应的文件夹目录,如

cd ~/Desktop/DebugLog

9)执行如下命令,即可正确解析crash文件

symbolicatecrash xxx.crash xxx.app.dSYM > test.txt

注意:symbolicatecrash的参数顺序,否则会报类似如下错误

Use of uninitialized value $data in substitution (s///) at /usr/bin/symbolicatecrash line 678.

Use of uninitialized value $data in substitution (s///) at /usr/bin/symbolicatecrash line 681.

Use of uninitialized value $data in substitution (s///) at /usr/bin/symbolicatecrash line 685.

Use of uninitialized value in pattern match (m//) at /usr/bin/symbolicatecrash line 404.

Use of uninitialized value in scalar assignment at /usr/bin/symbolicatecrash line 418.

No crash report version in XXX.app.dSYM/ at /usr/bin/symbolicatecrash line 954.

今天就先到这里,希望对大家有所帮助。

时间: 2025-01-19 15:30:10

iOS通过dSYM文件分析crash的相关文章

[Mac OS/iOS]反汇编工具Hopper分析Crash Log

   在Mac OS下分析Crash Log有很多种方法,这里不是要说明如何分析的Crash Log, 主要是展示下Hopper的使用. 强大的IDA大家可能已经知道,但它的Mac OS版本又让人回到了DOS时代.幸运的是Mac OS有了一个小巧的替代品:Hopper, 基本上满足了工作上的反汇编的需要,包括伪代码以及控制流图(Control Flow Graph),支持ARM指令集并对Objective-C的做了优化.   先给张界面总览(左侧是符号列表,打开程序后,用工具栏最右侧的Read

iOS系统Crash文件分析方法

  Xcode 4.3的symbolicatecrash的位置和老版本的不一致了. /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/ Xcode 4.3之前 /Developer/Platforms/iPhoneOS.platform/Develo

框架-ssh后台怎么接受安卓和ios端发送文件怎么接受,

问题描述 ssh后台怎么接受安卓和ios端发送文件怎么接受, 我后台用的ssh框架,在安卓和ios上传文件的时候老接受不到文件,求方法, 解决方案 前端发送multipart格式的数据,你在后台接收一下这个,并转化一下,springMVC中用multipart接收,strtus2中你就在对应的action中写private File myFile;//提交文件名称,然后set/get,这样你就得到file类型的文件了,在写到服务器中 解决方案二: 有例子么?你这种我也试了的 解决方案三: str

php类:XML文件分析类

XMLParser.class.php <?php /** XML 文件分析类 * Date: 2013-02-01 * Author: fdipzone * Ver: 1.0 * * func: * loadXmlFile($xmlfile) 读入xml文件输出Array * loadXmlString($xmlstring) 读入xmlstring 输出Array */ class XMLParser{ /** 读取xml文件 * @param String $xmlfile * @retu

使用Eclipse Memory Analyzer进行堆转储文件分析

简介: Eclipse Memory Analyzer(MAT)是著名的跨平台集成开发环境 Eclipse Galileo 版本的 33 个组成项目中之一,它是一个功能丰富的 JAVA 堆 转储文件分析工具,可以帮助你发现内存漏洞和减少内存消耗.本文主要介绍如 何安装配置 Memory Analyzer,并结合一个实例,介绍如何利用 MAT 来进行堆转 储文件分析,找到内存泄露的根源. 概述 对于大型 JAVA 应用程序来说,再精细的测试也难以堵住所有的漏洞,即便我 们在测试阶段进行了大量卓有成

ios下移动文件方法汇总

  这篇文章主要给大家汇总了一下ios下移动文件方法,从简单到复杂,十分的实用,有需要的小伙伴可以参考下. 这段objective c代码用于移动指定路径下的文件 代码如下: if ([fileManager copyItemAtPath:@"FilePath1" toPath:@"FilePath2" error:NULL]) { NSLog(@"Copied successfully"); } 方法二: 使用 NSFileManager: 让

通过Android trace文件分析死锁ANR实例过程_Android

对于从事Android开发的人来说,遇到ANR(Application Not Responding)是比较常见的问题.一般情况下,如果有ANR发生,系统都会在/data/anr/目录下生成trace文件,通过分析trace文件,可以定位产生ANR的原因.产生ANR的原因有很多,比如CPU使用过高.事件没有得到及时的响应.死锁等,下面将通过一次因为死锁导致的ANR问题,来说明如何通过trace文件分析ANR问题. 对应的部分trace文件内容如下: "PowerManagerService&qu

dump文件分析-access violation at location 0x000000000000

问题描述 access violation at location 0x000000000000 关机时,程序异常结束,内存不可读写. dump文件分析得到的调用堆栈如下: 根据上面的调用堆栈,好像是回调函数出现问题.请问如何准确定位到代码错误位置? 解决方案 你标框的地方不是已经告诉你了出错的代码文件,行数了,你打开对应的代码分析看看 解决方案二: Unhandled exception at 0x00000000 in CallDll.exe: 0xC0000005: Access viol

ART世界探险(12) - OAT文件分析(2) - ELF文件头分析(中)

ART世界探险(12) - OAT文件分析(2) - ELF文件头分析(中) 段(section)的概念 一块内存分配给应用程序之后,从代码的组织上,我们就有将它们分段的需求. 比如,可以分为代码段,数据段,只读数据段,堆栈段,未初始化的数据段等等. 在GAS汇编器中,我们通过.section伪指令来指定段名.ARM编译器我买不起,我就忽略它了. 标准section 段的描述 默认段名 代码段 .text 经过初始化的数据段 .data 未经初始化的数据段 .bss BSS是Block Star