iOS分析崩溃日志

前言

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

dYSM文件

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

崩溃日志

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

NSConcreteMutableAttributedString addAttribute:value:range:: nil value

(null)

((

CoreFoundation                      0x0000000185c642f4  + 160

libobjc.A.dylib                    0x00000001974880e4 objc_exception_throw + 60

CoreFoundation                      0x0000000185c64218  + 0

Foundation                          0x0000000186a9dfb4  + 152

Xmen                                0x10073fb30 Xmen + 7600944

Xmen                                0x1006bbbf4 Xmen + 7060468

UIKit                              0x000000018a9a47fc  + 60

UIKit                              0x000000018a9a512c  + 104

UIKit                              0x000000018a6b2b6c  + 88

UIKit                              0x000000018a9a4fd4  + 444

UIKit                              0x000000018a78e274  + 1012

UIKit                              0x000000018a999aac  + 2904

UIKit                              0x000000018a785268  + 172

UIKit                              0x000000018a6a1760  + 580

QuartzCore                          0x0000000189fe9e1c  + 152

QuartzCore                          0x0000000189fe4884  + 320

QuartzCore                          0x0000000189fe4728  + 32

QuartzCore                          0x0000000189fe3ebc  + 276

QuartzCore                          0x0000000189fe3c3c  + 528

QuartzCore                          0x0000000189fdd364  + 80

CoreFoundation                      0x0000000185c1c2a4  + 32

CoreFoundation                      0x0000000185c19230  + 360

CoreFoundation                      0x0000000185c19610  + 836

CoreFoundation                      0x0000000185b452d4 CFRunLoopRunSpecific + 396

GraphicsServices                    0x000000018f35b6fc GSEventRunModal + 168

UIKit                              0x000000018a70afac UIApplicationMain + 1488

Xmen                                0x1008cf9c0 Xmen + 9238976

libdyld.dylib                      0x0000000197b06a08  + 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,找到崩溃代码那一行:

2030896-46b84b37cf488cf1.png

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

结语

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

转载自:http://www.cocoachina.com/ios/20161221/18391.html

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,362评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,330评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,247评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,560评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,580评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,569评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,929评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,587评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,840评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,596评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,678评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,366评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,945评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,929评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,165评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,271评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,403评论 2 342

推荐阅读更多精彩内容