IOS崩溃日志解析(crash log)

IOS的应用程序少不了crash,互联网统计分析工具友盟有一项目错误分析的功能,专门用于应用程序崩溃日志统计,最近研究友盟上统计到的崩溃日志,在此对崩溃日志做一个简单的总结。

IOS崩溃日志分类:

一、低内存崩溃:IOS设备检测到低内存时,虚拟内存系统发出通知请求应用释放内存。这些通知发送到所有正在运行的应用和进程,试图收回一些内存。如果内存使用依然居高不下,系统将会终止后台线程以缓解内存压力。如果可用内存足够,应用将能够继续运行而不会产生崩溃报告。否则,应用将被iOS终止,并产生低内存崩溃报告。低内存崩溃日志上没有应用线程的堆栈回溯。相反,上面显示的是以内存页数为单位的各进程内存使用量。(一个内存页的大小是4KB)被iOS因释放内存页终止的进程名称后面你会看到jettisoned 字样。如果看到它出现在你的应用名称后面,说明你的应用因使用太多内存而被终止了。

二、常见Exception Codes:

0x8badf00d: 读做 “ate bad food”该编码表示应用是因为发生watchdog超时而被iOS终止的。  通常是应用花费太多时间而无法启动、终止或响应用系统事件。这类crash有可能是在极差网络情况下并且有启动APP的时候同步网络阻塞主线程导致的崩溃,所以我们应该尽可能地把一些需要耗时间的任务如同步网络搬离主线程,使得应用程序能够正常启动。

0xbaaaaaad:用户按住Home键和音量键,获取当前内存状态,不代表崩溃

0xbad22222:VoIP 应用因为过于频繁重启而被终止。

0xc00010ff:因为太烫了被干掉,意为“cool off”

0xdead10cc:读做 “dead lock”!该代码表明应用因为在后台运行时占用系统资源,如通讯录数据库不释放而被终止

0xdeadfa11:读做 “dead fall”! 该代码表示应用是被用户强制退出的。根据苹果文档, 强制退出发生在用户长按开关按钮直到出现 “滑动来关机”, 然后长按 Home按钮。强制退出将产生 包含0xdeadfa11 异常编码的崩溃日志, 因为大多数是强制退出是因为应用阻塞了界面。

三、常见Exception types:

查看我们的crash分析报告邮件,会发现最经常遇到的错误类型是SEGV(Segmentation Violation,段违例),表明内存操作不当,比如访问一个没有权限的内存地址。

当我们收到SIGSEGV信号时,可以往以下几个方面考虑:
1)、访问无效内存地址,比如访问Zombie(僵尸)对象;
2)、尝试往只读区域写数据;
3)、引用空指针;
4)、使用未初始化的指针;
5)、栈溢出;

此外,还有其它常见信号:
SIGABRT:收到Abort信号,可能自身调用abort()或者收到外部发送过来的信号;
SIGBUS:总线错误。与SIGSEGV不同的是,SIGSEGV访问的是无效地址(比如虚存映射不到物理内存),而SIGBUS访问的是有效地址,但总线访问异常(比如地址对齐问题);
SIGILL:尝试执行非法的指令,可能不被识别或者没有权限;
SIGFPE:Floating Point Error,数学计算相关问题(可能不限于浮点计算),比如除零操作;
SIGPIPE:管道另一端没有进程接手数据;

三、解析崩溃日志:

获取一份crash崩溃日志,我们需要把十六进制地址等原始信息映射为源代码级别的方法名称和代码行数,使其对开发人员可读。这个过程称为符号化解析。要成功地符号化(Symbolication)解析一份crash日志,我们需要有对应的应用程序二进制文件以及符号(.dSYM)文件。

下面主要针对友盟上常见的crash log 进行解析

看一下,crash log中有这么一行崩溃日志

6   appname                               0x350f3b appname + 3460923

同时堆栈信息后面还有一行:
dSYM UUID: B52242B9-C4FD-3750-8D3B-AB313091F44D根据crash log,得到App的UUID。UUID是个字符串,由32个字符组成。得到了UUID,你才能知道是你的哪个版本在用户的iPhone上出了问题。

这样, 我们去我们的dSYM文件看看我们的UUID是否和崩溃日志上的UUID一致,只有dSYM文件的UUID和崩溃日志上的UUID一致,我们才能正确把crash 日志符号化。 dwarfdump是MAC上的一个免费小工具,可以用这个小工具去检测我们APP的UUID (以下过程都是终端上完成)1、 命令是:dwarfdump --uuid golo.app.dSYM/ (先进入到我们的/Users/username/Documents/mydocment/appname.xcarchive/dSYMs/目录)如果此时提示xcrun: error: active developer path ("/Volumes/Xcode/Xcode.app/Contents/Developer") does not exist, use xcode-select to change2、这个时候,我们使用sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer/ 命令(这个命令的用意还有研究中)3、完了我们再次键入命令:dwarfdump --uuid golo.app.dSYM/此时就不会现出现1中的错误提示了,而是提示:UUID:B52242B9-C4FD-3750-8D3B-AB313091F44D (armv7) appname.app.dSYM/Contents/Resources/DWARF/appname
到这里, 我们就可以看到,我们的dSYM文件的UUID和我们的crash log的UUID一致,到这里,我们的准备工作结束接下来,解析crash log:4、在终端键入命令:dwarfdump --arch=armv7 --lookup 0x350f3b /Users/username/Documents/mydocment/appname.xcarchive/dSYMs/gaappname.app.dSYM/Contents/Resources/DWARF/appname

此时,不出意外的话,应该显示Looking up address: 0x0000000000350f3b in .debug_info... found!0x006e52dd: Compile Unit: length = 0x0000806a  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x006ed34b)0x006e52e8: TAG_compile_unit [1] *  AT_producer( "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)" )  AT_language( DW_LANG_ObjC ) AT_name( "/Users/mydocment/myClass.m" )

AT_low_pc( 0x0034d8fc )

AT_stmt_list( 0x00181846 )

AT_comp_dir( "/Users/launch007/dev/golo" )

AT_APPLE_optimized( 0x01 )

AT_APPLE_major_runtime_vers( 0x02 )

0x006e997f:     TAG_subprogram [60] *

AT_name( "__66-[myClass coustomMethod]_block_invoke" )

AT_decl_file( "/Users/mydocment/myClass.m"

AT_decl_line( 454 )

AT_prototyped( 0x01 )

AT_APPLE_isa( 0x01 )

AT_accessibility( DW_ACCESS_public )

AT_low_pc( 0x00350bd8 )

AT_high_pc( 0x0035110c )

AT_frame_base( r7 )

0x006e99c5:  TAG_lexical_block [43] *

AT_low_pc( 0x00350c06 )

AT_high_pc( 0x003510ec )

0x006e99ce:   TAG_lexical_block [42] *

AT_ranges( 0x0001fc90

[0x00350c06 - 0x00350f6a)

[0x003510d8 - 0x003510ec)

End )

0x006e99d3:  TAG_lexical_block [42] *

AT_ranges( 0x0001fca8

[0x00350c0e - 0x00350f6a)

[0x003510d8 - 0x003510ec)

End )

0x006e99e4:   TAG_lexical_block [42] *

AT_ranges( 0x0001fcc0

[0x00350c1a - 0x00350f5c)

[0x003510d8 - 0x003510de)

End )

0x006e99e9:    TAG_lexical_block [42] *

AT_ranges( 0x0001fcd8

[0x00350c62 - 0x00350f5c)

[0x003510d8 - 0x003510de)

End )

Line table dir : ‘/Users/mydocment‘

Line table file: ‘myClass.m‘ line 486, column 0 with start address 0x0000000000350ef0

Looking up address: 0x0000000000350f3b in .debug_frame... found!

0x00046620: FDE

length: 0x0000000c

CIE_pointer: 0x00000000

start_addr: 0x00350bd8 __66-[myClass coustomMethod]_block_invoke

range_size: 0x00000534 (end_addr = 0x0035110c)

Instructions: 0x00350bd8: CFA=4294967295+4294967295

到这里,我们解析完全,已经定位到是myClass类coustomMethod方法中line 486这一行出现崩溃,去对代码修改代码就好了。。。
时间: 2024-12-26 10:28:16

IOS崩溃日志解析(crash log)的相关文章

获取iOS 设备上崩溃日志 (Crash Log)的方法

1. iTunes同步获取 大部分用户会使用iTunes软件来管理iPhone,这样同步的Crash日志就会同步到电脑上,我们需要在特定的路径里面查找 Mac OS X:~/Library/Logs/CrashReporter/MobileDevice 2. 使用第三方软件 : itools等 使用itools第三方软件对iPhone设备管理,打开高级功能 --崩溃日志,然后将需要的日志导出到电脑里

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

今天突然发现了一个解析iOS crash log的好方法,忍不住来分享一下. 相信每个做iOS开发的TX都应该不会对symbolicatecrash陌生,我们第一次遇到真机上产生的崩溃日志时,在网上搜到的大部分教程都告诉我们说要用symbolicatecrash来解析crash log,我信了,所以相当长一段时间内,我都是用这个工具来解析crash log的. 每次都去敲命令来解析crash log本身就是一件很蛋疼的事情,但这还不是麻烦的,最麻烦的是用symbolicatecrash还经常遇到

常用获取Android崩溃日志和IOS崩溃日志的几种方法

一:前言 在日常测试app时,经常会遇到崩溃问题,测试快速抓取到崩溃日志可以有效方便开发进行定位,快速解决问题所在测试做到测试分析,定位是非常重要的,这也是判断一个测试能力指标的一大维度. 二:Android崩溃日志 一.通过adb logcat获取 # 清除日志,新手上路时,日志内容很多,对于能毕现的日志,可以先清除后重新获取 adb logcat -c # 然后再次运行崩溃操作,再抓取日志 # 存储日志到当前目录下的 carsh.log 中 adb logcat -d *:W > crash

iOS崩溃日志

今天看crash report ,有这样两个crash: 调用 stopUpdatingLocation 函数的是一个CLLocationManager 类型的对象,为什么报错的时候会把这个对象转成NSConcerteAttributedString类型? 调用getEsubmissionResult方法的是一个UIViewController类型的对象,为什么会转成_NSCFString类型? iOS崩溃日志 >> ios 这个答案描述的挺清楚的:http://www.goodpm.net/

ios 崩溃日志揭秘

http://www.raywenderlich.com/zh-hans/30818/ios%E5%BA%94%E7%94%A8%E5%B4%A9%E6%BA%83%E6%97%A5%E5%BF%97%E6%8F%AD%E7%A7%98 0x8badf00d: 读做 "ate bad food"! (把数字换成字母,是不是很像 :p)该编码表示应用是因为发生watchdog超时而被iOS终止的.  通常是应用花费太多时间而无法启动.终止或响应用系统事件. 0xbad22222: 该编码

iOS 崩溃日志 Backtrace的符号化

iOS的崩溃日志配合dsym文件可以找到崩溃时的backtrace,这是解决崩溃的最重要的信息. 如果是在同一台mac上打包, 导入crash log时候会自动将backtrace符号化,可以看到方法名, 文件名和行号 但是,有时候发版的包不是在你的mac上打包的,xcode找不到对应的符号表, backtrace没能符号化如下所示: Last Exception Backtrace:0 CoreFoundation 0x2cb535f2 __exceptionPreprocess + 1221

iOS崩溃日志 如何看

转载至搜狗测试 日志主要分为六个部分:进程信息.基本信息.异常信息.线程回溯.线程状态和二进制映像. 我们在进行iPhone应用测试时必然会在"隐私"中找到不少应用的崩溃日志,但是不会阅读对于很多人来说简直头疼.在此为大家详细介绍一下具体的阅读方法,希望大家可以更快的定位BUG.首先我们先看一下从iPhone中随机抽出的一个Crash日志: //1. 进程信息 Hardware Model: iPhone9,1 Process: com.sogou.sogouinput.BaseKey

iOS崩溃日志分析-b

1名词解释 1.1. UUID 一个字符串,在iOS上每个可执行文件或库文件都包含至少一个UUID,目的是为了唯一识别这个文件. 1.2. dwarfdump 苹果提供的命令行工具,其中一些功能就是查看可执行文件或库文件的UUID.示例: dwarfdump --uuid 应用名称.app/应用名称 dwarfdump --uuid 应用名称.dSYM 1.3. symbolicatecrash 苹果提供的命令行工具,可以将crash日志符号化为可读的堆栈信息.XCode6/XCode7版本中,

使用atos分析iOS崩溃日志

当APP出现崩溃时,一般会在XCode的Device界面里面出现崩溃日志,大概像这样: Incident Identifier: FBF87174-405D-4F1C-A745-E3D9F7858F4F CrashReporter Key: 31da19c0a9879bc6ca613ad7611c14ccebe2a82d Hardware Model: iPhone4,1 Process: MyProj [285] Path: /var/mobile/Applications/C6E9AF9C-