解析iOS線上崩潰日志(crash Log)

1、錯(cuò)誤類型

開發(fā)中遇到應(yīng)用崩潰是在所難免的，可以進(jìn)行斷點(diǎn)等一步一步的調(diào)試。但是APP上線之后也可能遇到一些bug，首先看一些這些線上app crash 信息：

* Application received signal SIGSEGV
* Application received signal SIGBUS
* -[NSConcreteMapTable keyboardWillShow:]: unrecognized selector sent to instance
* -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds for empty array
* -[JKArray objectAtIndex:]: index (0) beyond bounds (0)
  • SIGSEGV、SIGBUS 和第三個(gè)一般是因?yàn)樵L問已被釋放的內(nèi)存或者調(diào)用不存在的方法導(dǎo)致的，
  • 余下兩個(gè)就是數(shù)組越界的問題了。

這些我們都是知道的，然后來看看具體的log信息：

Application received signal SIGSEGV
unrecognized selector sent to instance

紅色框?qū)?yīng)的是 ：dSYM UUID
黑色框?qū)?yīng)的是：異常內(nèi)存地址

2、解析方法

2.1、使用友盟錯(cuò)誤分析工具

友盟iOS錯(cuò)誤分析功能說明

友盟錯(cuò)誤分析工具下載

2.2、使用dSYM 文件解析

<1> 什么是 dSYM 文件

Xcode編譯項(xiàng)目后，我們會(huì)看到一個(gè)同名的 dSYM 文件，dSYM 是保存 16 進(jìn)制函數(shù)地址映射信息的中轉(zhuǎn)文件，我們調(diào)試的 symbols 都會(huì)包含在這個(gè)文件中，并且每次編譯項(xiàng)目的時(shí)候都會(huì)生成一個(gè)新的 dSYM 文件，位于 /Users/<用戶名>/Library/Developer/Xcode/Archives 目錄下，對于每一個(gè)發(fā)布版本我們都很有必要保存對應(yīng)的 Archives 文件 ( AUTOMATICALLY SAVE THE DSYM FILES 這篇文章介紹了通過腳本每次編譯后都自動(dòng)保存 dSYM 文件)。

<2> dSYM 文件有什么作用

當(dāng)我們軟件 release 模式打包或上線后，不會(huì)像我們在 Xcode 中那樣直觀的看到用崩潰的錯(cuò)誤，這個(gè)時(shí)候我們就需要分析 crash report 文件了，iOS 設(shè)備中會(huì)有日志文件保存我們每個(gè)應(yīng)用出錯(cuò)的函數(shù)內(nèi)存地址，通過 Xcode 的 Organizer 可以將 iOS 設(shè)備中的 DeviceLog 導(dǎo)出成 crash 文件，這個(gè)時(shí)候我們就可以通過出錯(cuò)的函數(shù)地址去查詢 dSYM 文件中程序?qū)?yīng)的函數(shù)名和文件名。大前提是我們需要有軟件版本對應(yīng)的 dSYM 文件，這也是為什么我們很有必要保存每個(gè)發(fā)布版本的 Archives 文件了。

<3> 如何解析dSYM 文件

打開terminal（終端），進(jìn)行查找和解析，大致步驟如下：

MacBook-Pro:~ myName$ cd /Users/<用戶名>/Library/Developer/Xcode/Archives

MacBook-Pro:Archives myName$ ls
2015-09-07  2015-11-03  2016-01-20  2016-05-30  2016-12-05
2015-09-11  2015-12-07  2016-03-01  2016-06-22  2016-12-13
2015-09-12  2016-01-05  2016-05-11  2016-06-30  2017-01-11
2015-09-14  2016-01-13  2016-05-12  2016-07-01  2017-03-11
2015-09-29  2016-01-14  2016-05-18  2016-08-12  2017-03-13
2015-11-02  2016-01-19  2016-05-23  2016-12-01

MacBook-Pro:Archives myName$ cd 2017-03-13

MacBook-Pro:2017-03-13 myName$ ls
xxx 2017-3-13 下午11.58.xcarchive

MacBook-Pro:2017-03-13 myName$ cd xxx\ 2017-3-13\ 下午11.58.xcarchive/

MacBook-Pro:xxx 2017-3-13 下午11.58.xcarchive myName$ ls
Info.plist  Products    SCMBlueprint    dSYMs

MacBook-Pro:xxx 2017-3-13 下午11.58.xcarchive myName$ cd dSYMs/

MacBook-Pro:dSYMs myName$ dwarfdump --uuid <項(xiàng)目名>.app.dSYM
UUID: 45733B26-456D-31A1-177C-7E8DE4EF7C15 (armv7) xxx.app.dSYM/Contents/Resources/DWARF/xxx
UUID: E46DBE29-9288-A32F-BC67-F7F4EA2149DF (arm64) xxx.app.dSYM/Contents/Resources/DWARF/xxx

MacBook-Pro:dSYMs myName$ dwarfdump --lookup 0x1000e4d54 -arch arm64 xxx.app.dSYM

----------------------------------------------------------------------
 File: xxx.app.dSYM/Contents/Resources/DWARF/xxx (arm64)
----------------------------------------------------------------------
Looking up address: 0x00000001000e4d54 in .debug_info... found!

0x0016524b: Compile Unit: length = 0x00001843  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x00166a92)

0x00165256: TAG_compile_unit [106] *
             AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.42.1)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "/Users/myName/Desktop/app/xxx/MyView.m" )
             AT_stmt_list( 0x0006b8d4 )
             AT_comp_dir( "/Users/myName/Desktop/app/xxx" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x00000001000e3370 )
             AT_high_pc( 0x00000001000e5d74 )

0x00165da2:     TAG_subprogram [121] *
                 AT_low_pc( 0x00000001000e4ccc )
                 AT_high_pc( 0x00000001000e4d6c )
                 AT_frame_base( reg29 )
                 AT_object_pointer( {0x00165dc1} )
                 AT_name( "-[MyView showinView:]" )
                 AT_decl_file( "/Users/myName/Desktop/app/xxx/MyView.m" )
                 AT_decl_line( 99 )
                 AT_prototyped( 0x01 )
                 AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/myName/Desktop/app/xxx'
Line table file: 'MyView.m' line 102, column 5 with start address 0x00000001000e4d48

Looking up address: 0x00000001000e4d54 in .debug_frame... not found.

1、進(jìn)入 dSYMs 文件夾

  • 進(jìn)入 Archives 文件夾：
cd /Users/<用戶名>/Library/Developer/Xcode/Archives
  • 查看 Archives 此文件夾下的列表：
ls
  • 選擇你要查找的文件夾進(jìn)入：
cd 2017-03-13
  • 查看 2017-03-13 此文件夾下的列表（列表下應(yīng)該只有一個(gè)）：
ls
  • 繼續(xù)進(jìn)入 xcarchive
cd xxx 2017-3-13 下午11.58.xcarchive
  • 繼續(xù)進(jìn)入 dSYMs 文件夾
cd dSYMs

2、查找 UUID
查看 xx.app.dSYM 文件的 UUID：

dwarfdump --uuid <項(xiàng)目名>.app.dSYM

會(huì)自動(dòng)輸出 UUID，如下：

UUID: 45733B26-456D-31A1-177C-7E8DE4EF7C15 (armv7) xxx.app.dSYM/Contents/Resources/DWARF/xxx
UUID: E46DBE29-9288-A32F-BC67-F7F4EA2149DF (arm64) xxx.app.dSYM/Contents/Resources/DWARF/xxx

注意：正常情況下，崩潰日志里面的 dSYM UUID（上面截圖里紅色框里） 一定會(huì)和此處輸出的一個(gè) UUID 一樣，這樣才能進(jìn)行下一步查找，如果不一樣你就是進(jìn)錯(cuò)文件夾了（2017-03-13 文件夾），這里我在輸出里面隨意進(jìn)行了一些修改。

3、查找 crash Log 的異常內(nèi)存地址
根據(jù)崩潰日志里 異常內(nèi)存地址、arm64的信息進(jìn)行查找：

dwarfdump --lookup 0x1000e4d54 -arch arm64 <項(xiàng)目名>.app.dSYM

輸出的結(jié)果：

----------------------------------------------------------------------
 File: xxx.app.dSYM/Contents/Resources/DWARF/xxx (arm64)
----------------------------------------------------------------------
Looking up address: 0x00000001000e4d54 in .debug_info... found!

0x0016524b: Compile Unit: length = 0x00001843  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x00166a92)

0x00165256: TAG_compile_unit [106] *
             AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.42.1)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "/Users/myName/Desktop/app/xxx/MyView.m" )
             AT_stmt_list( 0x0006b8d4 )
             AT_comp_dir( "/Users/myName/Desktop/app/xxx" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )
             AT_low_pc( 0x00000001000e3370 )
             AT_high_pc( 0x00000001000e5d74 )

0x00165da2:     TAG_subprogram [121] *
                 AT_low_pc( 0x00000001000e4ccc )
                 AT_high_pc( 0x00000001000e4d6c )
                 AT_frame_base( reg29 )
                 AT_object_pointer( {0x00165dc1} )
                 AT_name( "-[MyView showinView:]" )
                 AT_decl_file( "/Users/myName/Desktop/app/xxx/MyView.m" )
                 AT_decl_line( 99 )
                 AT_prototyped( 0x01 )
                 AT_APPLE_optimized( 0x01 )
Line table dir : '/Users/myName/Desktop/app/xxx'
Line table file: 'MyView.m' line 102, column 5 with start address 0x00000001000e4d48

Looking up address: 0x00000001000e4d54 in .debug_frame... not found.

看一下結(jié)果：發(fā)現(xiàn)有 AT_name、Line table dir、Line table file，這樣就找到了出錯(cuò)的地方（MyView showinView: 方法出錯(cuò)了）。

注意：如果發(fā)現(xiàn) warning: unsupported file type: 錯(cuò)誤，這個(gè)問題是因?yàn)橛形募蛘吣夸浀拿Q中包含空格，比如：2017-3-13/xxx 8-30-13 6.19 ，所以，需要轉(zhuǎn)義一下：2017-3-13/xxx\ 8-30-13\ 6.19\ xxx.xcarchive。最好要cd進(jìn)入下一級的名稱從當(dāng)前的ls列表復(fù)制過去。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • iOS開發(fā)中，經(jīng)常遇到App在開發(fā)及測試時(shí)不會(huì)有問題，但是裝在別人的設(shè)備中會(huì)出現(xiàn)各種不定時(shí)的莫名的 crash，因...
    咖咖嘻閱讀 6,302評論 3贊 21
  • 如果大家是用真機(jī)在調(diào)試的過程中出現(xiàn)了Crash，那么請看iOS調(diào)試之 crash log分析 前言 導(dǎo)讀：Unde...
    KODIE閱讀 6,612評論 7贊 12
  • 本文就捕獲iOS Crash、Crash日志組成、Crash日志符號(hào)化、異常信息解讀、常見的Crash五部分介紹。...
    xukuangbo_閱讀 1,734評論 0贊 0
  • 解析崩潰日志 一 獲取crash 1.用戶把設(shè)備連接到電腦上，打開xcode－window，選中Devices－當(dāng)...
    大蝦咪閱讀 6,228評論 4贊 3
  • 關(guān)鍵詞 花 肥料 死了 一顆花 去年，我一直想給家里增添一點(diǎn)綠色，去花店左挑右...
    任性的王海川閱讀 1,013評論 2贊 1

友情鏈接更多精彩內(nèi)容