使用symbolicatecrash分析crash文件

  对于我们iOS开发者来说,最心碎的事莫过于苹果审核一个星期后上架app store,而第二天就报出闪退bug。一周前我刚经历过,而且最坑的是由于第一次做个人开发,经验不足,没有集成友盟的分析SDK,还好有几个好心同事下载了,然后果然有两台机器上出现了闪退。真是天无绝人之路,最重要的crash文件有了。下面我就来详细描述一下具体的心路历程以及分析方法。

  iOS app的所有崩溃记录都会记录在设备上,所以对于和我一样没有集成让用户发送崩溃报告功能的iOS开发者来说,要获得crash文件就必须先连上崩溃过的机器,然后打开Xcode,选择Window -> Devices(如果是Xcode6以下,则是Window -> Organizer -> Devices),选择你自己的机器,然后点击View Device Logs,这时候会打开一个小窗口,这就是你机器上至目前为止存的所有app的崩溃信息了。如果是好久没看过这个信息,打开后还要读取好久才能完全读完,总之,找到你的app最后一次崩溃记录,右键导出。(先不要在意下图的信息,我只是随便找了一个)

我们先看一眼导出来的.crash文件,上半部分都是一些基本信息(基本没用),重点看下崩溃部分的记录,如下图(是下图,不是上图!)

看红框里的,隐隐有种不翔的预感,很像是数组越界之类的问题啊,可下边几行写的都是啥,这怎么定位问题啊。先不管了,先在桌面上建个文件夹,就叫crash吧,然后把这个导出的.crash文件扔进去。想要再详细点的记录还缺几样东西呢。。。

  找到你上次发布的ipa(如果实在没有了就再从Archives里导出来一个,但一定要保证是你上次发布用的那个),右键 -> 打开方式 -> 归档实用工具(就是解压缩),然后把Payload文件夹下的.app文件也扔到刚刚的crash文件夹里。

  接下来还需要dSYM文件,还是在Archives里,找到发布用的那个,右键Show in Finder,如图

然后对文件夹中的这个.xcarchive文件右键,显示包内容,就可以看到一个名为dSYMs的文件夹,把里面的.dSYM文件拷出来,还是放到桌面的crash文件夹里。好了,还剩一个重头了,就是标题上说的symbolicatecrash工具。

  symbolicatecrash是一个隐藏工具,它在我的Mac中的具体路径如下(Xcode6.1.app请换成你的Xcode名称)

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

你也可以在终端中输入命令搜索:

find /Applications/Xcode6.1.app -name symbolicatecrash -type f

把这个路径拷贝一下,然后粘到Finder的“前往文件夹”下,前往,就可以看到symbolicatecrash工具了,现在把它也拷到桌面的crash文件夹里。至此,crash文件夹里现在有4个文件了,分别是.app, .crash, .dSYM, symbolicatecrash。接下来就是用终端敲命令,生成更易分析的crash。

  首先用cd命令进入到crash文件夹下,然后输入以下命令

./symbolicatecrash /Users/xxxx/Desktop/crash/InOrder.crash /Users/xxxx/Desktop/crash/InOrder.app.dSYM > Control_symbol.crash

上述命令中,"xxxx"和"InOrder"请自行替换成对应的名称。运行,这时候终端可能会报错Error: "DEVELOPER_DIR" is not defined at /usr/local/bin/symbolicatecrash line 53. 这时候在终端中再输入如下(Xcode6.1.app依然是要替换成实际名称)

export DEVELOPER_DIR="/Applications/Xcode6.1.app/Contents/Developer"

然后再跑一下刚刚的那个命令,这时候看一下桌面的crash文件夹下就会多出一个名为“Control_symbol.crash”的文件,这就是可定位问题的crash文件了,我们打开看一下。

现在红框里原来的那些乱七八糟的东西已经“翻译”成了崩溃在具体的哪一个.m文件的哪一行。下面就是进行合理的猜想和调试了,比如我的崩溃就是因为这个第三方时间选择控件使用截取字符串的形式来获得时间,像09:23 PM就被固定的拆成了时、分、上下午标识3段,结果用户使用24小时制的时候,时间就成了21:23,没了上下午标识,array[2]超出下标妥妥的闪退。想想我脑洞也是蛮大的,这种问题原因都被猜到了。。。

  转自:http://www.cnblogs.com/ningxu-ios/p/4141783.html?utm_source=tuicool

时间: 2024-11-09 02:22:50

使用symbolicatecrash分析crash文件的相关文章

[iOS]使用symbolicatecrash分析crash文件

对于我们iOS开发者来说,最心碎的事莫过于苹果审核一个星期后上架app store,而第二天就报出闪退bug.一周前我刚经历过,而且最坑的是由于第一次做个人开发,经验不足,没有集成友盟的分析SDK,还好有几个好心同事下载了,然后果然有两台机器上出现了闪退.真是天无绝人之路,最重要的crash文件有了.下面我就来详细描述一下具体的心路历程以及分析方法. iOS app的所有崩溃记录都会记录在设备上,所以对于和我一样没有集成让用户发送崩溃报告功能的iOS开发者来说,要获得crash文件就必须先连上崩

分析iOS Crash文件:符号化iOS Crash文件的3种方法

转自:http://www.cocoachina.com/industry/20140514/8418.html 转自wufawei的博客 当你的应用提交到App Store或者各个渠道之后,请问你多久会拿到crash文件?你如何分析crash文件的呢? 上传crash文件 你的应用应当有模块能够在应用程序crash的时候上传crash信息. 要么通过用户反馈拿到crash文件,要么借助自己或第3方的crash上传模块拿到crash文件. 今天要分析的场景是你拿到用户的.crash文件之后,如何

分析iOS Crash文件,使用命令符号化iOS Crash文件

TBMainClient.ipa改名为TBMainClient.zip并解压得到TBMainClient.app 然后将TBMainClient.app      TBMainClient.app.dSYM   TBMainClient.crash  三个文件放到一个文件夹下,然后终端下命令进入文件夹. 依次运行: export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer /Applications/Xcode.app/Con

苹果官方 Crash文件分析方法 (iOS系统Crash文件分析方法)

对于提交的苹果官方的app,在审核的时候会给我们一些crash文件,对于这些有用的文件,里面是关于我们的bug的一些信息,那么该如何去调试呢 第一步:在任意目录创建一个目录,用来调试crash,我这里创建一个crash目录 第二步:将之前Archive的文件copy到crash目录里面 其中包括两个文件.app和.app.dSYM 如果找不到的话可以按照下面的步骤进行 先到Organizer 1,找到提交那个时刻的Archive文件,选中,show in Finder 2,然后到达这里,然后再选

ios crash文件分析

http://www.cnblogs.com/yingkong1987/p/3157692.html http://blog.sina.com.cn/s/blog_a573f7990101gi4k.html http://stackoverflow.com/questions/3609084/ipad-app-works-on-most-devices-gets-exc-crash-sigabrt-on-some 新建一个专门的目录进行解析处理,如: /crash 把对应的.app和.dSYM文

Xcode7.3工具解析App崩溃日志(.crash文件)

Xcode7.3工具解析App崩溃日志(.crash文件) 原文链接:http://blog.csdn.net/u011056605 开发的App或者游戏提交审核后,偶尔会收到测试反馈的消息,说应用崩溃了,bug偶尔出现,难以找到确定的重现方法. 怎么办?可以分析崩溃文件啊,也就是app崩溃后,自动保存在设备本地的.crash文件. 获得崩溃日志的方式,在 获取设备上的调试信息与崩溃日志分析 中有说. 在环境ok的情况下,xcode中是可以自动解析.crash文件的.旧版本的xcode甚至可以导

iOS-----分析iOS Crash文件:符号化iOS Crash文件的3种方法

iOS Crash 分析(文一)- 开始 1. 名词解释 1. UUID 一个字符串,在iOS上每个可执行文件或库文件都包含至少一个UUID.目的是为了唯一识别这个文件. 2. dwarfdump 苹果提供的命令行工具,其中一些功能就是查看可执行文件件或库文件的UUID 3. symbolicatecrash 一个苹果提供的脚本.可以将crash日志符号化为可读的堆栈信息. 4. atosl 苹果提供的命令行工具,可以将crash的base_address和load_address转化为可读的堆

iOS- 全方位解析.crash文件崩溃报告

1.前言 想来每个iOS攻城狮,都免不了要接触.crash文件 那么什么是.crash文件? iOS app的所有崩溃记录都会记录在设备上,所以对于和我一样没有集成让用户发送崩溃报告功能的iOS开发者来说,要获得crash文件就必须先连上崩溃过的机器,然后从崩溃过的机器上导出.crash文件 2.如何解析.crash文件 我们先看一眼导出来的.crash文件,重点看下崩溃部分的记录 如下图 显然从这图里,我们没法定位出具体的错误,和崩溃的具体行数. 我们得到是个二进制的报告,这时候我们需要对它进

iOS: Crash文件解析(一)

iOS Crash文件的解析(一) 开发程序的过程中不管我们已经如何小心,总是会在不经意间遇到程序闪退.脑补一下当你在一群人面前自信的拿着你的App做功能预演的时候,流畅的操作被无情地Crash打断.联想起老罗在发布Smartisan OS的时候说了,他准备了10个手机,如果一台有问题,就换一台,如果10台后挂了他就不做手机了.好了不闲扯了,今天就跟大家一起聊聊iOSCrash文件的组成以及常用的分析工具. 有一个WWDC 2010的视频推荐大家抽空看看,视频名称“Understanding C