别用symbolicatecrash来解析crash Log了by 风之枫

今天突然发现了一个解析iOS crash log的好方法,忍不住来分享一下。

相信每个做iOS开发的TX都应该不会对symbolicatecrash陌生,我们第一次遇到真机上产生的崩溃日志时,在网上搜到的大部分教程都告诉我们说要用symbolicatecrash来解析crash log,我信了,所以相当长一段时间内,我都是用这个工具来解析crash log的。

每次都去敲命令来解析crash log本身就是一件很蛋疼的事情,但这还不是麻烦的,最麻烦的是用symbolicatecrash还经常遇到问题:怎么crash log又解析失败了?怎么批量解析crash log?

问题出在方法上,实际上我们完全用不着symbolicatecrash的,因为Xcode中自带的organizer就是很好的解析crash log工具了。

举个例子,如果我们的应用是在自己的机器上编译生成的,把应用装在真机上如果有崩溃产生,把真机通过数据线连接到Mac电脑上,打开Xcode菜单上的Window——Organizer,找到设备的device logs项中的crash log,稍等片刻,你就会发现这里的crash log已经被自动解析过了(大部分情况会自动解析,如果不行请右键点击选择Re-Sysbomlicate)。

但是如果应用不是在自己的编译上生成的,你会发现organizer不会自动解析crash log(除了系统函数)。怎么在这种情况下也让organizer也能自动解析crash log呢?

其实之前的organizer之所以能自动解析你设备上的crash log,是因为它能根据spotlight的索引来找到对应的.app和dSYM文件,对于这一点,我的猜测是在自己的Mac电脑上编译生成应用时,系统自动对其进行了索引。这个索引应该是根据app uuid来索引的。这个uuid可以执行下面的命令得到:

dwarfdump —uuid YourApp.app/YourApp 
dwarfdump —uuid YourApp.app.dSYM

如果要能解析出crash log,crash log中携带的uuid与dSYM文件的uuid必须与app uuid一致。

既然spotlight能自动进行索引,那是不是也可以手动进行索引呢?答案是能,这正是自动解析的关键。手动索引的命令是mdimport。比如,把iOS应用的.app和.dSYM文件放到一个文件夹中,执行命令mdimport foldername就可以。命令执行完成后再用刚才的organizer去查看crash log,你会发现也能自动解析了。

这意味着什么呢?意味着你把应用所有版本的.app和.dSYM文件放入一个专门的文件夹中,只要mdimpor这个文件夹,以后的organizer就能自动解析出你所有的crash log。

好处不仅仅是这一点。organizer还有一个import功能,借助这个功能,我们可以把其它Mac电脑上的crash log导入到自己电脑中的organizer,然后就可以自动解析。更好的是,用这个功能可以批量导入收集到的crash log,然后我们就可以批量解析所有的crash log。

比起用symbolicatecrash,这种方法简便了许多,从现在起,你可以抛弃symbolicatecrash了。但其实这还不是最好的方法,目前先进的方法是用crash report管理系统来管理所有的crash,比如使用QuincyKit, Crashlytics, Flurry等来进行管理,有时间自己也研究研究。

原文地址:http://www.cnblogs.com/max5945/p/3663966.html

时间: 2024-11-25 21:22:05

别用symbolicatecrash来解析crash Log了by 风之枫的相关文章

IOS崩溃日志解析(crash log)

IOS的应用程序少不了crash,互联网统计分析工具友盟有一项目错误分析的功能,专门用于应用程序崩溃日志统计,最近研究友盟上统计到的崩溃日志,在此对崩溃日志做一个简单的总结. IOS崩溃日志分类: 一.低内存崩溃:IOS设备检测到低内存时,虚拟内存系统发出通知请求应用释放内存.这些通知发送到所有正在运行的应用和进程,试图收回一些内存.如果内存使用依然居高不下,系统将会终止后台线程以缓解内存压力.如果可用内存足够,应用将能够继续运行而不会产生崩溃报告.否则,应用将被iOS终止,并产生低内存崩溃报告

iOS crash log 解析

iOS开发中,经常遇到App在开发及测试时不会有问题,但是装在别人的设备中会出现各种不定时的莫名的 crash,因为iOS设备会保存应用的大部分的 crash Log,所以可以通过 crash Log 来定位 crash 原因. 一. 获取iOS设备上的 crash log 1. 将iOS设备连接到电脑上,打开 Xcode -> Organizer -> Devices,找到该台设备,在 Device logs 中找到 crash log(后缀为 .crash 的 log 文件),将其导出即可

IOS Crash Log 分析

上架AppStroe 被打回来了,原因是: Your app crashed on iPad running iOS 11.3.1 connected to an IPv6 network when we tapped on profile image. We have attached detailed crash logs to help troubleshoot this issue. 崩溃日志 一.Crash文件结构 当程序运行Crash的时候,系统会把运行的最后时刻的运行信息记录下来,

IOS crash log分析

此处不讨论具体的如何根据.dsym文件解析crash log的方式. 一.一般的崩溃 1.违反苹果的政策:启动.恢复.暂停或退出超时; 用户强制退出: 低内存退出:MemoryWarning; 2.程序中有bug 二.崩溃解析说明 1.MemoryWarning的崩溃比较特别,没有任何trace,标志性信息即某一条trace后面有“jettisoned”. 解决方法: 可用Allocations.Leaks Instruments 或VM Tracker Instrument来帮助检查.另外,解

Crash log符号化与调试信息

这篇文章主要整理了crash log的符号化解析和调试信息与配置相关的一些内容. 对于做移动App开发的来说,质量和体验都是很重要的.一个客户端应用如果经常“闪退”,是产品质量很差的一个体现,用户体验就更不用提了.所以开发一个优秀的App,首先是保证自身的技术质量,尽量杜绝“闪退”,也就是“Crash”.但客户端上线后,偶尔出现一个隐藏很深的bug也在所难免.我们所能做的就是尽可能的收集问题相关的信息,争取在将来的新版本中解决和改进. 0. Crash 一个App启动之后,用着用着就突然被iOS

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

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

Android Native/Tombstone Crash Log 详细分析(转)

转自:http://weibo.com/p/230418702c2db50102vc2h Android 虽然已经有好几年了,但是NDK的开放速度却非常缓慢,所以目前网络上针对对Android NativeCrash的分析说明还比较少,尤其是非常详细的分析方式更难以查询.因此大部分程序员在遇到难以进行addr2line的crashlog时,会一筹莫展.事实上这份log中的其他部分同样提供了非常丰富的信息可供解读,所以在这里总结一下对在这方面的一些经验,在这里以Androidsamples中的he

Android dump .so 文件crash log

众所周知,在android系统上,有时候我们遇到so文件的crash只能打log,但是很多时候并不知道crash在什么地方,幸运的是crash后,一般可以产生一个.dmp文件. 我们可以根据这个文件来得到更为详细的statck trace. 主要用的就是google提供的一些方法,命令太复杂,很容易出错,所以我写了一个python脚本,简化步骤. 详情可以参考 https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide #!

crash log具体流程概述

crash log具体流程概述 当某服务或者native code程序crash产生调试信息后有两中去向: 1.写入到logcat: 这种信息可以通过adb shell中的logcat中察看到. 2.写入到系统的/data/tombstones/文件夹中: 创建tombstone_xx文件后写入信息,xx 从00开始,最大支持49个tombstone_xx文件,超出后会从00开始重新写入覆盖之前. 当某一进程crash以后会向系统发送信号,信号在某个地方会被拦截下来发送给android的处理函数