iOS Crash 分析(文一)- 开始

iOS Crash 分析(文一)- 开始


1. 名词解释

1. UUID

一个字符串,在iOS上每个可执行文件或库文件都包含至少一个UUID。目的是为了唯一识别这个文件。

2. dwarfdump

苹果提供的命令行工具,其中一些功能就是查看可执行文件件或库文件的UUID

3. symbolicatecrash

一个苹果提供的脚本。可以将crash日志符号化为可读的堆栈信息。

4. atosl

苹果提供的命令行工具,可以将crash的base_address和load_address转化为可读的堆栈信息。symbolicatecrash就是使用这个命令来做符号化的。

2.如何获取Crash日志

1.模拟器崩溃

模拟器崩溃后可以在“~/Library/Logs/DiagnosticReports/”下找到crash日志。

2.真机崩溃

1.Xcode获取日志

手机和mac连接后,打开Xcode选择window进入Organizer(快捷方式是 Shift-CMD-2),在 Organizer 窗口上, 选中 Devices 标签栏. 在左侧的导航面板上,选中 Device Logs, 如下图所示:

选择对应设备的Device Logs菜单,就可以看到崩溃日志。

打开图最上边的Device Logs菜单就可以看到mac曾经同步过的iOS设备的崩溃日志。

2.手动获取日志

日志存放的路径 ~/Library/Logs/CrashReporter/MobileDevice/DEVICE_NAME

DEVICE_NAME是你想要查看的设备。

下面是我的终端输出的信息:

?  DiagnosticReports  pwd
/Users/zhuolaiqiang/Library/Logs/DiagnosticReports
?  DiagnosticReports  ls
QQ_2014-05-30-132026_Anyhacker.crash            atosl_2014-06-04-151416_Anyhacker.crash         eclipse_2014-05-29-192522_Anyhacker.crash       eclipse_2014-06-02-145714_Anyhacker.crash
SogouInput_2014-05-29-151154_Anyhacker.crash    atosl_2014-06-04-151447_Anyhacker.crash

3.符号化

1.利用Xcode符号化

app在真机设备上Crash后,我们可以让iOS设备和mac连接,然后打开Xcode选择window进入Organizer(快捷方式是 Shift-CMD-2),在 Organizer 窗口上, 选中对应设备的 Device Logs标签,然后找到对应app日志文件,如图所示:

这样就可以看到已经符号化完毕的日志。

2.利用symbolicatecrash脚本符号化

symbolicatecrash是苹果随Xcode一起提供的专门用来做崩溃日志符号化的脚本工具(perl)。

symbolicatecrash存放路径是

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

使用方法是:

symbolicatecrash xx.crash xx.DSYM

xx.crash:需要符号化的崩溃日志文件

xx.DSYM:编译APP时产生的DSYM文件,此文件可以不指定,symbolicatecrash会在硬盘内自动搜索和匹配该文件(前提是你的硬盘内存有这个文件)

时间: 2024-12-24 22:13:48

iOS Crash 分析(文一)- 开始的相关文章

iOS Crash 分析(文二)-崩溃日志组成

iOS Crash 分析(文二)-崩溃日志组成 现在我们看一个淘宝iOS主客崩溃的例子: ### 1.进程信息 ### Incident Identifier: E4201F10-6F5F-40F9-B938-BB3DA8ED7D50 CrashReporter Key: TODO Hardware Model: iPhone4,1 Process: Taobao4iPhone [3538] Path: /var/mobile/Applications/E3B51E77-D44D-4B3E-87

iOS Crash 分析(文三)- 符号化崩溃日志

iOS Crash 分析(文三)- 符号化崩溃日志 未符号化的崩溃日志就象一本天书,看不懂,更别谈分析崩溃原因了.所以我们在分析日志之前,要把日志翻译成我们可以看得懂的文字.这一步我们称之为符号化. 在iOS Crash分析(文一)中已经提到过符号化的两种方式: 1.利用Xcode符号化 2.利用symbolicatecrash脚本符号化 其实这两种分析方式都使用了同一个工具符号化:***atos***. atos是苹果提供的符号化工具,在Mac OS系统下默认安装. 使用***atos***符

iOS Crash 分析 符号化崩溃日志

参考: http://blog.csdn.net/diyagoanyhacker/article/details/41247367 http://blog.csdn.net/diyagoanyhacker/article/details/41247389 http://blog.csdn.net/diyagoanyhacker/article/details/41247411 http://www.cnblogs.com/smileEvday/p/Crash1.html 未符号化的崩溃日志就象一

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 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的时候,系统会把运行的最后时刻的运行信息记录下来,

符号化(Symbolicating) iOS Crash文件

今天有空研究一下如何分析iOS Crash文件. 看了一下网上的方法,有些行不通了.最后拿老大以前写的脚本,可以了. 然后理解了一下脚本,最后稍作修改.整理一下. 脚本(在Mac上面运行): echo dSYM uuid: xcrun dwarfdump --uuid $2.app.dSYM/Contents/Resources/DWARF/$2 echo crashlog uuid: grep $2' armv7' $1 | tr -s " " echo baseaddress: g

iOS: Crash文件解析(一)

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

漫谈iOS Crash收集框架

漫谈iOS Crash收集框架 为了能够第一时间发现程序问题,应用程序需要实现自己的崩溃日志收集服务,成熟的开源项目很多,如 KSCrash,plcrashreporter,CrashKit 等.追求方便省心,对于保密性要求不高的程序来说,也可以选择各种一条龙Crash统计产品,如 Crashlytics,Hockeyapp ,友盟,Bugly 等等. 是否集成越多的Crash日志收集服务就越保险? 自己收集的Crash日志和系统生成的Crash日志有分歧,应该相信谁? 为什么有大量Crash日

jvm crash分析

问题描述:线上进程异常退出,查看服务器端日志,有jvm crash文件生成 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f385c182889, pid=31877, tid=139878461208320 # # JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build