2. 程式人生 > >教你如何對ios崩潰(crash)日誌做符號化

教你如何對ios崩潰(crash)日誌做符號化

阿新 • • 發佈：2019-01-04

一、場景

        客戶端的開發流程都相似，如android，搞ios開發就要不停地發版本，隨之而來的就是各種版本的崩潰日誌（稱為crash log）。如果不能好好地管理，那麼開發人員很快就會在crash log和版本的海洋裡迷失方向。解決崩潰問題是移動應用開發者最日常的工作之一。如果是開發過程中遇到的崩潰，可以根據重現步驟除錯，但線上版本就無能為力了。

        國內，一般的公司是沒有對ios crash符號化分析系統的，能夠對ios 的crash日誌做符號化做得好的公司比較少，比較好的是 “騰訊bugly”，連結：http://bugly.qq.com 。ios的日誌分析，做符號化，並定位到發生崩潰的原因，對app的開發百利無一害，功德無量。

        關注問題本身，客戶端開發和後臺服務開發管理日誌有很大的不同：

        如果是伺服器報了個異常，對於java的服務，RD登上機器，看看錯誤的日誌，看到“crash by...” 找出原因，改程式碼，重新編譯打包部署一下就算修復了，假如是分散式的叢集，服務是可以不間斷的提供服務的。

        如果是客戶端開發，在實際的專案開發中，崩潰問題，依賴xcode編輯器，依賴於系統記錄的崩潰日誌或錯誤堆疊，在本地開發除錯階段，是沒有問題的。如果在釋出的線上版本出現崩潰問題，開發者是無法即時準確的取得錯誤堆疊的。需要適當的時期將crash上報到服務端，由服務端處理收集分析。客戶端需要重新發版才能修復舊版的crash。

      下面對ios的crash 管理做一下介紹，因為android開發是java語言，不需要做額外的處理。

二、例子

下面線上iphone的原始crash日誌：

### 1.程序資訊 ###
Incident Identifier: 87164E05-84A8-40F2-886D-14F90C9D3F47
CrashReporter Key:   TODO
Hardware Model:      iPhone7,2
Process:         imeituan [945]
Path:            /var/mobile/Containers/Bundle/Application/96DC918D-60C8-4C49-A51D-C0D71D0FCB4D/imeituan.app/imeituan
Identifier:      com.meituan.imeituan
Version:         895
Code Type:       ARM-64
Parent Process:  ??? [1]
 
### 2.基本資訊 ###
Date/Time:       2016-02-01 16:14:24 +0000
OS Version:      iPhone OS 9.2.1 (13D15)
Report Version:  104
 
### 3.異常資訊 ###
Exception Type:  SIGABRT
Exception Codes: #0 at 0x181f3c140
 
### 4.執行緒回溯 ###
Crashed Thread:  0
Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 25 beyond bounds [0 .. 24]'
 
### 5.Crash呼叫堆疊，需要需要將堆疊的二進位制轉成可讀的###
Last Exception Backtrace:
0   CoreFoundation                      0x0000000182399900 0x182274000 + 1202432
1   libobjc.A.dylib                     0x0000000181a07f80 0x181a00000 + 32640
2   CoreFoundation                      0x000000018227f828 0x182274000 + 47144
3   imeituan                            0x0000000101ab593c 0x1000b8000 + 27253052
4   imeituan                            0x0000000100521a68 0x1000b8000 + 4627048
5   UIKit                               0x00000001873dd31c 0x187078000 + 3560220
6   UIKit                               0x00000001873dd484 0x187078000 + 3560580
7   UIKit                               0x00000001873cc7e8 0x187078000 + 3491816
8   UIKit                               0x00000001873e1fb0 0x187078000 + 3579824
9   UIKit                               0x000000018717708c 0x187078000 + 1044620
10  UIKit                               0x0000000187087778 0x187078000 + 63352
11  QuartzCore                          0x0000000184a96b2c 0x184a88000 + 60204
12  QuartzCore                          0x0000000184a91738 0x184a88000 + 38712
13  QuartzCore                          0x0000000184a915f8 0x184a88000 + 38392
14  QuartzCore                          0x0000000184a90c94 0x184a88000 + 35988
15  QuartzCore                          0x0000000184a909dc 0x184a88000 + 35292
16  QuartzCore                          0x0000000184a8a0cc 0x184a88000 + 8396
17  CoreFoundation                      0x0000000182350588 0x182274000 + 902536
18  CoreFoundation                      0x000000018234e32c 0x182274000 + 893740
19  CoreFoundation                      0x000000018234e75c 0x182274000 + 894812
20  CoreFoundation                      0x000000018227d680 0x182274000 + 38528
21  GraphicsServices                    0x000000018378c088 0x183780000 + 49288
22  UIKit                               0x00000001870f4d90 0x187078000 + 511376
23  imeituan                            0x0000000100112628 0x1000b8000 + 370216
24  ???                                 0x0000000181e1e8b8 0x0 + 0
 
 … 

### 6.動態庫資訊 ###
Binary Images:
       0x1000b8000 -        0x10275ffff +imeituan arm64  <e38d01be571931b7a4c3d9dcbf28e821> /var/mobile/Containers/Bundle/Application/96DC918D-60C8-4C49-A51D-C0D71D0FCB4D/imeituan.app/imeituan
       0x10d76c000 -        0x10d7dbfff  AGXMetalG4P arm64  <f76b11f8d06338f99ae4704aba08111c> /System/Library/Extensions/AGXMetalG4P.bundle/AGXMetalG4P
       0x182058000 -        0x18225dfff  libicucore.A.dylib arm64  <5c1540546de5350ab314c1d4c8a46d1b> /usr/lib/libicucore.A.dylib
       
 	…

       0x182274000 -        0x1825ecfff  CoreFoundation arm64  <121118a9a44d3518b99f3ebfd8806f69> /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
       0x1825f0000 -   

       …

主要有6部分組成:

  • 1.程序資訊
  • 2.基本資訊
  • 3.異常資訊
  • 4.執行緒回溯
  • 5.Crash呼叫堆疊（全是地址資訊，需要使用符號表轉成可讀的）
  • 6.動態庫資訊（第5部分依賴的庫）

 ios的符號化也主要是根據第5和第6部分進行符號化，只有把第五部分後面的二進位制的地址資訊對映成程式碼資訊，才能發生crash的原因。

下面是上面的crash日誌符號化後的結果：

### 1.程序資訊 ###
Incident Identifier: 87164E05-84A8-40F2-886D-14F90C9D3F47
CrashReporter Key:   TODO
Hardware Model:      iPhone7,2
Process:         imeituan [945]
Path:            /var/mobile/Containers/Bundle/Application/96DC918D-60C8-4C49-A51D-C0D71D0FCB4D/imeituan.app/imeituan
Identifier:      com.meituan.imeituan
Version:         895
Code Type:       ARM-64
Parent Process:  ??? [1]

### 2.基本資訊 ###
Date/Time:       2016-02-01 16:14:24 +0000
OS Version:      iPhone OS 9.2.1 (13D15)
Report Version:  104

### 3.異常資訊 ###
Exception Type:  SIGABRT
Exception Codes: #0 at 0x181f3c140

### 4.執行緒回溯 ###Crashed Thread:  0
Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 25 beyond bounds [0 .. 24]'

### 5.Crash呼叫堆疊，需要需要將堆疊的二進位制轉成可讀的###
Last Exception Backtrace:
0   CoreFoundation                      __exceptionPreprocess + 124
1   libobjc.A.dylib                     objc_exception_throw + 56
2   CoreFoundation                      -[__NSArrayM removeObjectAtIndex:] + 0
3   imeituan                            -[SAKFetchedResultsController objectAtIndexPath:] (SAKFetchedResultsController.m:60)
4   imeituan                            -[DEFHomePageViewController tableView:cellForRowAtIndexPath:] (DEFHomePageViewController.m:663)
5   UIKit                               -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 692
6   UIKit                               -[UITableView _createPreparedCellForGlobalRow:willDisplay:] + 80
7   UIKit                               -[UITableView _updateVisibleCellsNow:isRecursive:] + 2360
8   UIKit                               -[UITableView _performWithCachedTraitCollection:] + 104
9   UIKit                               -[UITableView layoutSubviews] + 176
10  UIKit                               -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 656
11  QuartzCore                          -[CALayer layoutSublayers] + 148
12  QuartzCore                          CA::Layer::layout_if_needed(CA::Transaction*) + 292
13  QuartzCore                          CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 32
14  QuartzCore                          CA::Context::commit_transaction(CA::Transaction*) + 252
15  QuartzCore                          CA::Transaction::commit() + 512
16  QuartzCore                          CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 80
17  CoreFoundation                      __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
18  CoreFoundation                      __CFRunLoopDoObservers + 372
19  CoreFoundation                      __CFRunLoopRun + 928
20  CoreFoundation                      CFRunLoopRunSpecific + 384
21  GraphicsServices                    GSEventRunModal + 180
22  UIKit                               UIApplicationMain + 204
23  imeituan                            main (main.m:34)
24  ???                                 0x0000000181e1e8b8 0x0 + 0

### 6.動態庫資訊 ###
Binary Images:
       0x1000b8000 -        0x10275ffff +imeituan arm64  <e38d01be571931b7a4c3d9dcbf28e821> /var/mobile/Containers/Bundle/Application/96DC918D-60C8-4C49-A51D-C0D71D0FCB4D/imeituan.app/imeituan
       0x10d76c000 -        0x10d7dbfff  AGXMetalG4P arm64  <f76b11f8d06338f99ae4704aba08111c> /System/Library/Extensions/AGXMetalG4P.bundle/AGXMetalG4P
       0x182058000 -        0x18225dfff  libicucore.A.dylib arm64  <5c1540546de5350ab314c1d4c8a46d1b> /usr/lib/libicucore.A.dylib
       
 	…

       0x182274000 -        0x1825ecfff  CoreFoundation arm64  <121118a9a44d3518b99f3ebfd8806f69> /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
       0x1825f0000 -   

       …

那怎麼將第5部分進行符號化呢？那就需要符號表了，什麼是符號表呢？符號表有什麼用？符號表怎麼生成？符號表怎麼用？

三、ios crash 日誌符號化過程

（1）什麼是符號表

符號表就是指在Xcode專案編譯後，在編譯生成的二進位制檔案.app的同級目錄下生成的同名的.dSYM檔案。.dSYM檔案其實是一個目錄，在子目錄中包含了一個16進位制的儲存函式地址對映資訊的中轉檔案，所有Debug的symbols都在這個檔案中(包括檔名、函式名、行號等)，所以也稱之為除錯符號資訊檔案。一般地，Xcode專案每次編譯後，都會生成一個新的.dSYM檔案。因此，App的每一個釋出版本，都需要備份一個對應的.dSYM檔案，以便後續除錯定位問題。

專案每一次編譯後，.app和.dSYM成對出現，並且二者有相同的UUID值，以標識是同一次編譯的結果。
UUID值可以使用dwarfdump —uuid來檢查：

 dwarfdump --uuid **.app.dSYM (**為你app)

例如：


（2）符號表有什麼用

       在Xcode開發除錯App時，一旦遇到崩潰問題，開發者可以直接使用Xcode的偵錯程式定位分析。
       但如果App釋出上線，開發者不可能進行除錯，只能通過分析系統記錄的崩潰日誌來定位問題，在這份崩潰日誌檔案中，會指出App出錯的函式記憶體地址，而這些函式地址是可以在.dSYM檔案中找到具體的檔名、函式名和行號資訊的，這正是符號表的重要作用所在，也是為什麼要進行符號表進行管理，並紀錄這是哪個版本的符號表。

Xcode的Organizer檢視崩潰日誌時，也自動根據本地儲存的.dSYM檔案進行了符號化的操作。並且，崩潰日誌也有UUID資訊，這個UUID和對應的.dSYM檔案是一致的，即只有當三者的UUID一致時，才可以正確的把函式地址符號化。

（3）符號表怎麼生成

         Xcode專案預設的配置是會在編譯後生成.dSYM，開發者無需額外修改配置。因為我也沒有進行過ios開發經驗，每個版本的符號表都是客戶端的負責人給我的。這裡省略。

（4）符號表怎麼用

  符號表的作用是把崩潰中的函式地址解析為函式名等資訊。如果開發者能夠獲取到崩潰的函式地址資訊，就可以利用符號表分析出具體的出錯位置。

Xcode提供了幾個工具來幫助開發者執行函式地址符號化的操作。

         例如，我們用上面的例子，從上面原始日誌的第5部分挑出crash的地址，崩潰問題的函式地址堆疊如下：

Last Exception Backtrace: 0   CoreFoundation                      0x0000000182399900 0x182274000 + 1202432 1   libobjc.A.dylib                     0x0000000181a07f80 0x181a00000 + 32640 2   CoreFoundation                      0x000000018227f828 0x182274000 + 47144

第一步：從第6部分找出所依賴的動態庫的地址

   “CoreFoundation”的動態庫是“/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation”：

0x182274000 -        0x1825ecfff  CoreFoundation arm64  <121118a9a44d3518b99f3ebfd8806f69> /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation

第二步：在符號表的該目錄下驗證uuid是不是對應上

執行命令dwarfdump --uuid 來驗證：

執行命令： dwarfdump --uuid /Users/jenkins/data/apps/OSSDKSymbols/9.2.1\ \(13D15\)/Symbols/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation 輸出： UUID: 121118A9-A44D-3518-B99F-3EBFD8806F69 (arm64) /Users/jenkins/data/apps/OSSDKSymbols/9.2.1 (13D15)/Symbols/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation UUID: 910B0F17-490F-3D92-9833-A9D4AADABBDB (armv7s) /Users/jenkins/data/apps/OSSDKSymbols/9.2.1 (13D15)/Symbols/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation

發現“121118A9-A44D-3518-B99F-3EBFD8806F69”和“121118a9a44d3518b99f3ebfd8806f69”是吻合的（忽略大小寫和‘－’），說明這個crash是在該版本中的。可以進行下面的符號化操作。

第三步：用atos工具進行符號化

atos實際是一個可以把地址轉換為函式名（包括行號）的工具，atos 語法：atos -o dysm檔案路徑 -l 模組load地址 呼叫方法的地址，上面的0x182274000就是模組load地，0x0000000182399900就是呼叫方法的地址。

例如執行命令：

執行命令： atos -o /Users/jenkins/data/apps/OSSDKSymbols/9.2.1\ \(13D15\)/Symbols/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation -l 0x182274000 0x0000000182399900 輸出： __exceptionPreprocess (in CoreFoundation) + 124

發現輸出的結果是：__exceptionPreprocess (in CoreFoundation) + 124，說明符號化成功

至此符號就成功了，這個例子只是ios的os的crash日誌符號化，還有就是app層面crash，上面全部的的符號化的結果都是根據這幾個步驟來完成的。

四、服務架構


       上面的符號化可以知道，我們需要"dwarfdump" 和 “atos” 命令，這是mac os 上帶的符號化的工具，同時還依賴xcode的版本，這是ubantu和centos系統所不支援的，所以crash log的符號化必須是在mac os上進行的，所以crash符號化服務必須在mac os進行，物理機可以是mac mini、imac或macbook。

       至於上面crash業務服務，可以使用一般的ubantu或centos 系統都是可以的。

       那麼問題來了，一般來說我們釋出的服務都是在ubantu或是centos系統上的，怎麼把服務部署在mac os機器上呢？其實都差不多，java因為有JVM，服務是跨平臺的，只是需要Runtime呼叫本地的“dwarfdump" 和 “atos”命令。無非就是編譯、打包、部署，當然了還有初始化機器，建立釋出賬號，建立路徑，管理服務程序等繁瑣的事情，這樣就可以把java服務釋出到遠端的mac os機器上，問題就可以解決了。


相關推薦

教你如何對ios崩潰(crash)日誌做符號化

一、場景         客戶端的開發流程都相似，如android，搞ios開發就要不停地發版本，隨之而來的就是各種版本的崩潰日誌（稱為crash log）。如果不能好好地管理，那麼開發人員很快就會在crash log和版本的海洋裡迷失方向。解決崩潰問題是移動應用開發者

指令碼處理iOS的Crash日誌

背景 當我們打包app時，可以選擇生成對應的符號表，其儲存 16 進位制函式地址對映資訊，通過給定的函式起始地址和偏移量，可以對應函式具體資訊以供分析。 所以我們拿到測試給的閃退日誌(.crash)時，需要找到打包時對應生成的符號表(.dSYM)作為鑰匙解析。具體分為下面幾個步驟 dwarfdump --u

iOS 記錄crash日誌

專案開發過程中經常會遇到crash的問題，現在有比較好的統計工具，但有時我們只是需要了解造成crash的原因，使用友盟等顯得有些浪費。現在可以自己動手寫記錄crash。 ZWCrashRecordTool添加了兩個方法： 初始化快取目錄 清除crash快取

iOS崩潰crash大解析

前言 iOS崩潰是讓iOS開發人員比較頭痛的事情，app崩潰了，說明程式碼寫的有問題，這時如何快速定位到崩潰的地方很重要。除錯階段是比較容易找到出問題的地方的，但是已經上線的app並分析崩潰報告就比較麻煩了。 之前我總是找到一個改一個，並靠別人測試重現來找出問題的地方，這樣

[原]手把手教你appium_第一個示例日誌解讀

1. 啟動一個http伺服器：127.0.0.1:4723 2. 根據測試程式碼setUp()進行初始化，在http伺服器上建立一個session物件； 3. 開始呼叫adb，找到連線上的裝置，設定裝置id 猜測：這次我只連線了一個模擬器，如果還有多個裝置呢，在第二篇文章中是命令列啟動的，使用了-U

教你用認知和人性來做最棒的程序員

清晰 公共函數 最重要的 財報 易懂 one 很好 測試的 phone 不久前，在團隊內部和大家做了一次分享，內容就是這次要講的“用認知和人性來提升自己的技術水平”，大家反響不錯，所以這次整理一下也分享給大家。最初我是想用“借優秀的產品經理思維來做最棒程序員”的這個標題，但

IOS崩潰Crash分析（MTA騰訊雲分析，友盟）

公司做IOS的走了，東西就丟給了我這個從來沒有做過IOS的。最近為了捕獲BUG，集成了MTA平臺的BUG收集。問題就來了，對於我這種，雖然沒有學過OC，但是寫寫程式碼還是可以的，xCode中除錯下BUG也行，但是碰到這種Crash的，還不帶崩潰路徑的，完全

iOS稽核總被拒？騰訊教你提升iOS稽核通過率！

作者：Jamie，騰訊開發工程師，在iOS預審和ASO優化領域從事專項測試相關工作，為騰訊遊戲近100個產品提供專項服務。 商業轉載請聯絡騰訊WeTest獲得授權，非商業轉載請註明出處。WeTest導讀眾所周知，蘋果應用商店是蘋果公司提供給開發者釋出和使用者下

一篇文章教你如何用 Python 記錄日誌

轉載：http://python.jobbole.com/89007/對一名開發者來說最糟糕的情況，莫過於要弄清楚一個不熟悉的應用為何不工作。有時候，你甚至不知道系統執行，是否跟原始設計一致。線上執行的應用就是黑盒子，需要被跟蹤監控。最簡單也最重要的方式就是記錄日誌。記錄日誌

手把手教你對APK進行二次簽名

哈嘍大家好，剛開始寫部落格，寫的不好的地方請見諒！也算是對自己工作的一個記錄吧。 由於專案中近期使用了梆梆安全加固，加固完成後需要對APK進行二次簽名！ 梆梆安全提供的簽名軟體不知道是不是環

一步步教你開發、部署第一個去中心化應用(Dapp) - 寵物商店

區塊鏈今天我們來編寫一個完整的去中心化（區塊鏈）應用（Dapps）, 本文可以和編寫智能合約結合起來看。 寫在前面 閱讀本文前，你應該對以太坊、智能合約有所了解，如果你還不了解，建議你先看以太坊是什麽除此之外，你最好還了解一些HTML及JavaScript知識。 本文通過實例教大家來開發去中心化應用，應用效果

20181117——一步步教你開發、部署第一個去中心化應用(Dapp) - 寵物商店

DApp是Decentralized Application 分散式應用 npm Node Package Manager. 包管理工具 用來下載安裝升級解除安裝安裝包 完了沒發出來，結果快取都沒了。 用MetaMask測試私有網路 從Ganache建立的賬戶中選擇一個匯入

【手把手教你】Python獲取財經資料和視覺化分析

內容來自：微信公眾號：python金融量化 關注可瞭解更多的金融與Python乾貨。 “巧婦難為無米之炊”，找不到資料，量化分析也就無從談起。對於金融分析者來說，獲取資料是量化分析的第一步。Python的一個強大功能之一就是資料獲取（爬蟲）。但是對於沒時間學爬蟲程式的小白來說，pytho

一步步教你開發、部署第一個去中心化應用(Dapp)

今天我們來編寫一個完整的去中心化（區塊鏈）應用（Dapps）, 本文可以和編寫智慧合約結合起來看。寫在前面閱讀本文前，你應該對以太坊、智慧合約有所瞭解，如果你還不瞭解，建議你先看以太坊是什麼除此之外，你最好還了解一些HTML及JavaScript知識。本文通過例項教大家來開發

遭遇Crash檔案戰：教你如何搞定iOS崩潰日誌

請叫我背景 最近在提交應用到App Store的時候，竟然被拒了兩次。那時候心裡的想法是，尼瑪完蛋了，要被老闆開除了，我是不是要失業了。於是乎那兩週幾乎毛腦子都是為什麼Apple你這麼狠心，我們明明相愛了那麼多年，你竟然就這樣拋棄了我。我不想活了，不要攔著我，我要分分

iOS Crash崩潰異常教你檢視和分析

要學會看crash崩潰和報告 一個應用程式並不總會一直執行的很好，它總會有出現crash崩潰的情況。如果在應用程式中接入了一些第三方的crash收集工具或者自建crash收集報告平臺的話將會很好的幫助開發者去分析和解決應用程式在線上執行的問題，當出現的崩潰問題

手把手教你做iOS的soap應用 webservice

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

一步一步教你做ios推送 pem證書製作 php推送

 最近在研究ios的推送問題，遇到了一些問題，最終整理了一下。放在這裡和大家分享 APNS的推送機制 首先我們看一下蘋果官方給出的對ios推送機制的解釋。如下圖 Provider就是我們自己程式的後臺伺服器，APNS是Apple Push Notification Service的縮寫，也就是

友盟抓取crash Log- 解析IOS崩潰日誌

http://blog.csdn.net/xyxjn/article/details/43310061 http://blog.csdn.net/smking/article/details/9342899 最近在解析ume

解析IOS崩潰日誌(crash Log)

http://lieyunye.github.io/blog/2013/09/10/how-to-analyse-ios-crash-log/ http://blog.csdn.net/smking/article/details/9342899 最近在解析umeng錯