IOS分析崩溃日志

标签: iphone ios xcode objective-c | 发表时间:2016-12-21 07:16 | 作者:苏小妖
出处:https://segmentfault.com/blogs

我的简书文章地址

前言

  IOS分析定位崩溃问题有很多种方式,但是发布到AppStore的应用如果崩溃了,我们该怎么办呢?通常我们都会在系统中接入统计系统,在系统崩溃的时候记录下崩溃日志,下次启动时将日志发送到服务端,比较好的第三方有umeng之类的。今天我们来讲一下通过崩溃日志来分析定位我们的bug。

dYSM文件

  分析崩溃日志的前提是我们需要有 dYSM文件,这个文件是我们用archive打包时生成的 .xcarchive后缀的文件包。一个良好的习惯是,在你打包提交审核的时候,将生成的.xcarchive与ipa文件一同拷贝一份,按照版本号保存下来,这样如果线上出现问题可以快速的找到你想要的文件来定位你的问题。

崩溃日志

一般崩溃日志都会像下面这样:

  NSConcreteMutableAttributedString addAttribute:value:range:: nil value
(null)
((
    CoreFoundation                      0x0000000185c642f4 <redacted> + 160
    libobjc.A.dylib                     0x00000001974880e4 objc_exception_throw + 60
    CoreFoundation                      0x0000000185c64218 <redacted> + 0
    Foundation                          0x0000000186a9dfb4 <redacted> + 152
    Xmen                                0x10073fb30 Xmen + 7600944
    Xmen                                0x1006bbbf4 Xmen + 7060468
    UIKit                               0x000000018a9a47fc <redacted> + 60
    UIKit                               0x000000018a9a512c <redacted> + 104
    UIKit                               0x000000018a6b2b6c <redacted> + 88
    UIKit                               0x000000018a9a4fd4 <redacted> + 444
    UIKit                               0x000000018a78e274 <redacted> + 1012
    UIKit                               0x000000018a999aac <redacted> + 2904
    UIKit                               0x000000018a785268 <redacted> + 172
    UIKit                               0x000000018a6a1760 <redacted> + 580
    QuartzCore                          0x0000000189fe9e1c <redacted> + 152
    QuartzCore                          0x0000000189fe4884 <redacted> + 320
    QuartzCore                          0x0000000189fe4728 <redacted> + 32
    QuartzCore                          0x0000000189fe3ebc <redacted> + 276
    QuartzCore                          0x0000000189fe3c3c <redacted> + 528
    QuartzCore                          0x0000000189fdd364 <redacted> + 80
    CoreFoundation                      0x0000000185c1c2a4 <redacted> + 32
    CoreFoundation                      0x0000000185c19230 <redacted> + 360
    CoreFoundation                      0x0000000185c19610 <redacted> + 836
    CoreFoundation                      0x0000000185b452d4 CFRunLoopRunSpecific + 396
    GraphicsServices                    0x000000018f35b6fc GSEventRunModal + 168
    UIKit                               0x000000018a70afac UIApplicationMain + 1488
    Xmen                                0x1008cf9c0 Xmen + 9238976
    libdyld.dylib                       0x0000000197b06a08 <redacted> + 4
)
dSYM UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: Xmen
Base Address: 0x000000010007c000

是不是看的一脸懵逼,下面我来教大家如何结合crash log 与 dYSM文件 来分析定位出代码崩溃在哪一个文件的哪一行代码

提取崩溃日志中有用的信息

  • NSConcreteMutableAttributedString addAttribute:value:range:: nil value 崩溃的原因是value为nil

  • " 4  Xmen                                0x10073fb30 Xmen + 7600944" 它指出了应用名称,崩溃时的调用方法的地址,文件的地址以及方法所在的行的位置,我们需要的是这一个:"0x10073fb30"。

  • "dSYM UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85"。

  • "CPU Type: arm64"。

开始分析

  • 打开终端进入到你的dYSM文件的目录下面:
    cd /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs

  • 验证下崩溃日志中的UUID与本地的dYSM文件是否是相匹配的:
    "Xmen"为你的app名称

dwarfdump --uuid Xmen.app.dSYM
结果是:

  UUID: BFF6AE00-8B5F-39BD-AFD0-27707C489B25 (armv7) Xmen.app.dSYM/Contents/Resources/DWARF/Xmen
UUID: 30833A40-0F40-3980-B76B-D6E86E4DBA85 (arm64) Xmen.app.dSYM/Contents/Resources/DWARF/Xmen

发现与我们日志中的:UUID和CPU Type是相匹配的

  • 查找错误信息
    dwarfdump --arch=arm64 --lookup 0x10073fb30  /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen

"arm64"与"0x1008cf9c0"分别对应于上面我们从日志中提取出来的有用信息
"/Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen"对应于你本地dYSM文件目录
"Xmen"对应于你的app名称
结果像下面这样:

  File: /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen (arm64)
Looking up address: 0x000000010073fb30 in .debug_info... found!
0x00219b05: Compile Unit: length = 0x00003dd0  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0021d8d9)
0x00219b10: TAG_compile_unit [107] *
AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.42.1)" )
AT_language( DW_LANG_ObjC )
AT_name( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
AT_stmt_list( 0x001272a9 )
AT_comp_dir( "/Dandy/checkSvn/IOS/xmen" )
AT_APPLE_major_runtime_vers( 0x02 )
AT_low_pc( 0x000000010072b8ac )
AT_high_pc( 0x000000010074e350 )
0x0021aec5:    TAG_subprogram [119] *
AT_low_pc( 0x0000000100739810 )
AT_high_pc( 0x000000010074006c )
AT_frame_base( reg29 )
AT_object_pointer( {0x0021aee3} )
AT_name( "-[DSSellerOrderSectionHeaderView updateContentWithOrderData:isEdit:]" )
AT_decl_file( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )
AT_decl_line( 248 )
AT_prototyped( 0x01 )
0x0021af36:        TAG_lexical_block [138] *
AT_ranges( 0x00008640
[0x000000010073cf90 - 0x000000010073fb88)
[0x000000010073fbc0 - 0x000000010073fbc4)
End )
Line table dir : '/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View'
Line table file: 'DSSellerOrderSectionHeaderView.m' line 680, column 9 with start address 0x000000010073faf8
Looking up address: 0x000000010073fb30 in .debug_frame... not found.

我们来从终端结果来分析出我们想要的结果:
这一行告诉我们崩溃的代码所在的文件的目录

  Line table dir : '/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View'

这一行告诉我们崩溃代码所在的具体文件

  AT_decl_file( "/Dandy/checkSvn/IOS/xmen/Xmen/Modules/StoreManage/SellerOrder/View/DSSellerOrderSectionHeaderView.m" )

这一行告诉我们崩溃代码是在哪一个方法里面

  AT_name( "-[DSSellerOrderSectionHeaderView updateContentWithOrderData:isEdit:]" )

这一行告诉我们崩溃代码具体在哪一行了

  Line table file: 'DSSellerOrderSectionHeaderView.m' line 680, column 9 with start address 0x000000010073faf8

好的,现在我们分析到了崩溃代码在哪一行了,下面我们来找一找bug

查找bug

  我们的代码都应该有托管平台,每个版本上线都需要打一个 tag,这是一个好习惯。下面我拉下我崩溃的对应版本的tag,找到崩溃代码那一行:

  结合崩溃日志中告诉我:崩溃的原因是value为nil,发现是因为receiverTelephone字段中有中文导致转url时为nil导致的,下面的解bug就看各自本领啦。

结语

  希望对您有帮助,谢谢支持~

相关 [ios 分析 日志] 推荐:

IOS分析崩溃日志

- - SegmentFault 最新的文章
  IOS分析定位崩溃问题有很多种方式,但是发布到AppStore的应用如果崩溃了,我们该怎么办呢. 通常我们都会在系统中接入统计系统,在系统崩溃的时候记录下崩溃日志,下次启动时将日志发送到服务端,比较好的第三方有umeng之类的. 今天我们来讲一下通过崩溃日志来分析定位我们的bug.   分析崩溃日志的前提是我们需要有 dYSM文件,这个文件是我们用archive打包时生成的 .xcarchive后缀的文件包.

iOS应用的crash日志的分析基础

- - CSDN博客移动开发推荐文章
一、如何获得crash日志. 当一个iOS应用程序崩溃时,系统会创建一份crash日志保存在设备上. 这份crash日志记录着应用程序崩溃时的信息,通常包含着每个执行线程的栈调用信息(低内存闪退日志例外),对于开发人员定位问题很有帮助. 如果设备就在身边,可以连接设备,打开Xcode - Window - Organizer,在左侧面板中选择Device Logs(可以选择具体设备的Device Logs或者Library下所有设备的Device Logs),然后根据时间排序查看设备上的crash日志.

iOS应用崩溃日志揭秘

- - 移动开发 - ITeye博客
转自  http://www.raywenderlich.com/zh-hans/30818/ios应用崩溃日志揭秘. Soheil Moayedi Azarpour, 他是一名独立iOS开发者. 作为一名应用开发者,你是否有过如下经历?. 为确保你的应用正确无误,在将其提交到应用商店之前,你必定进行了大量的测试工作.

GC 日志分析

- - 码蜂笔记
不同的JVM及其选项会输出不同的日志. 生成下面日志使用的选项: -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:d:/GClogs/tomcat6-gc.log. 最前面的数字 4.231 和 4.445 代表虚拟机启动以来的秒数.

apache日志分析简介

- - 编程语言 - ITeye博客
如果apache的安装时采用默认的配置,那么在/logs目录下就会生成两个文件,分别是access_log和error_log. access_log为访问日志,记录所有对apache服务器进行请求的访问,它的位置和内容由CustomLog指令控制,LogFormat指令可以用来简化该日志的内容和格式.

goaccess分析nginx日志

- - C1G军火库
GoAcces是一款实时日志分析工具. 目前,我们可以通过这款软件查看的统计信息有:. 静态web请求,如图片、样式表、脚本等. 支持超大日志(分析速度很快). GoAccess的基本语法如下:. -b – 开启流量统计,如果希望加快分析速度不建议使用该参数. -s – 开启HTTP响应代码统计. -a – 开启用户代理统计.

gc日志分析工具

- - Web前端 - ITeye博客
性能测试排查定位问题,分析调优过程中,会遇到要分析gc日志,人肉分析gc日志有时比较困难,相关图形化或命令行工具可以有效地帮助辅助分析. 通过在tomcat启动脚本中添加相关参数生成gc日志. -verbose.gc开关可显示GC的操作内容. 打开它,可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等.

Windows IIS日志文件分析程序

- bababubuliku - 月光博客
  Windows Server具有事件日志记录的功能,其IIS日志文件里记录了包括下列信息:谁访问了您的站点,访问者查看了哪些内容等等. 通过定期检查这些日志文件,网站管理员可以检测到服务器或站点的哪些方面易受攻击或存在其他安全隐患.   不过,目前的日志分析工具并不是很完善,有些功能并不具备,特别是针对某个URL地址进行攻击的分析并不多,下面是一个VB Script程序,保存为VBS程序后可以在服务器上运行,用于分析和检测IIS日志里针对某个URL地址进行攻击的IP地址.

日志分析方法概述

- jin - 搜索研发部官方博客
日志在计算机系统中是一个非常广泛的概念,任何程序都有可能输出日志:操作系统内核、各种应用服务器等等. 日志的内容、规模和用途也各不相同,很难一概而论. 本文讨论的日志处理方法中的日志,仅指Web日志. 其实并没有精确的定义,可能包括但不限于各种前端Web服务器——apache、lighttpd、tomcat等产生的用户访问日志,以及各种Web应用程序自己输出的日志.

谈日志采集和分析

- - 人月神话的BLOG
本篇为杂谈,只谈一个日志采集分析工具实现过程中的关键点. 对于log文件的采集需要支持分布式的集群,从多个集群机器进行日志采集. 同时日志采集需要对日志文件进行类似流处理的增量实时采集,类似flume工具的一种实现模式. 日志采集不是目的,而基于采集后的日志实时处理,实时处理后的实时分析才是重点. 日志文件本身是一个非结构化的文本文件,但是里面又包含了可以结构化出来的信息,因此对于日志文件是最适合采用mongoDB这种数据库进行存储.