iOS崩潰堆疊符號化,定位問題分分鐘搞定!

2021-07-09 16:11:13 字數 3385 閱讀 1483

最近一段時間,在跟開發者溝通過程中,蘿莉發覺大家對ios的應用符號表還不是很清楚,除了諮詢關於符號表生成、配置的問題以外,對bugly崩潰分析需要配置符號表也存在疑問。

在這裡,蘿莉就給大家分享下關於ios符號表的一些內容。

首先,進行常識「腦補」。

1. 符號表是什麼?

.dsym檔案其實是乙個目錄,在子目錄中包含了乙個16進製制的儲存函式位址對映資訊的中轉檔案,所有debug的symbols都在這個檔案中(包括檔名、函式名、行號等),所以也稱之為除錯符號資訊檔案。

注意:專案每一次編譯後,

和.dsym

成對出現,並且二者有相同的

uuid

值,以標識是同一次編譯的產物。

uuid

值可以使用

dwarfdump —uuid

來檢查:

那麼,問題就來了!

2. 符號表有什麼用?

實際上,使用xcode的organizer檢視崩潰日誌時,也自動根據本地儲存的

.dsym

檔案進行了符號化的操作。

並且,崩潰日誌也有

uuid

資訊,這個

uuid

和對應的

.dsym

檔案是一致的,即只有當三者的uuid一致時,才可以正確的把函式位址符號化。

專案的

build settings

的相關配置如下:

generate debug symbols = yes

debug information format = dwarf with dsym file

採用不同的編譯打包方式,產生的.dsym檔案的路徑也不相同。

下面是幾種常用的編譯打包方式:

1、使用xcodebuild編譯打包

2、使用xcode的archive匯出

3、使用make編譯打包

如果開發團隊不使用xcode編譯打包,而是使用make編譯生成.o檔案,然後打包發布。此時,編譯過程不會有.dsym檔案生成。開發者可以使用dsymutil工具從.o檔案中提取符號資訊。

4. 符號表怎麼用?

在前面的內容可以知道,符號表的作用是把崩潰中的函式位址解析為函式名等資訊。

如果開發者能夠獲取到崩潰的函式位址資訊,就可以利用符號表分析出具體的出錯位置。

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

例如,崩潰問題的函式位址堆疊如下:

錯誤位址堆疊

3  corefoundation           0x254b5949 0x253aa000 + 1096008

4 corefoundation 0x253e6b68 _cf_forwarding_prep_0 + 24

5 supersdktest 0x0010143b 0x000ef000 + 74808

符號化堆疊

3   corefoundation          0x254b5949 + 712

4 corefoundation 0x253e6b68 _cf_forwarding_prep_0 + 24

5 supersdktest 0x0010143b -[viewcontroller didtriggerclick:] + 58

說明:

大部分情況下,開發者能獲取到的都是錯誤位址堆疊,需要利用符號表進一步符號化才能分析定位問題。

部分情況下,開發者也可以利用backtrace看到符號化堆疊,可以大概定位出錯的函式、但卻不知道具體的位置。通過利用符號表資訊,也是可以進一步得到具體的出錯位置的。

目前,許多崩潰監控服務都顯示backtrace符號化堆疊,增加了可讀性,但分析定位問題時,仍然要進一步符號化處理。

崩潰資訊的uuid

下面,利用兩個工具來進行一下符號化的嘗試:

1、symbolicatecrash

symbolicatecrash是乙個將堆疊位址符號化的指令碼,輸入引數是蘋果官方格式的崩潰日誌

及本地的.dsym檔案,執行方式如下

使用symbolicatecrash

工具的限制就在於只能分析官方格式的崩潰日誌,需要從具體的裝置中匯出,獲取和操作都不是很方便,而且,符號化的結果也是沒有具體的行號資訊的,也經常會出現符號化失敗的情況。

實際上xcode

的organizer

內建了symbolicatecrash工具,所以開發者才可以直接看到符號化的錯誤日誌。

2、atos

更普遍的情況是,開發者能獲取到錯誤堆疊資訊,而使用atos工具就是把位址對應的具體符號資訊找到。

atos實際是乙個可以把位址轉換為函式名(包括行號)的工具,它的執行方式如下:

$ xcrun atos -o executable -arch architecture -l loadaddress

address ...

說明:loadaddress 表示函式的動態載入位址,對應崩潰位址堆疊中 + 號前面的位址,即0x000ef000

address 表示執行時位址、對應崩潰位址堆疊中第乙個位址,即0x0010143b

實際上,崩潰位址堆疊中+號前後的位址相加即是執行時位址,即0x000ef000 + 74808 = 0x0010143b

執行命令查詢位址的符號,可以看到如下結果:

0x0010143b

-[viewcontroller didtriggerclick:] (in supersdktest) (viewcontroller.m:35)

開發者在具體的運用中,是可以通過編寫乙個指令碼來實現符號化錯誤位址堆疊的。

5. 結語

在實際的專案開發中,崩潰問題的分析定位都不是採用這種方式,因為它依賴於系統記錄的崩潰日誌或錯誤堆疊,在本地開發除錯階段,是沒有問題的。

目前,國內外提供崩潰監控服務的產品有好幾個,在崩潰問題的統計上可能不分伯仲。但提供自動符號化功能的產品卻基本沒有,大部分崩潰問題的堆疊只是簡單符號化以增強可讀性,沒有可以快速定位問題的行號資訊。

Xcode 崩潰堆疊符號化,定位崩潰

首先,進行常識 腦補 1.符號表是什麼?dsym檔案其實是乙個目錄,在子目錄中包含了乙個16進製制的儲存函式位址對映資訊的中轉檔案,所有debug的symbols都在這個檔案中 包括檔名 函式名 行號等 所以也稱之為除錯符號資訊檔案。注意 來檢查 那麼,問題就來了!2.符號表有什麼用?實際上,使用x...

iOS崩潰堆疊符號化,定位問題分分鐘搞定!

最近一段時間,在跟開發者溝通過程中,蘿莉發覺有些開發者對ios的應用符號表還不是很清楚,除了諮詢關於符號表生成 配置的問題以外,對bugly崩潰分析需要配置符號表也存在疑問。在這裡,蘿莉就給大家分享下關於ios符號表的一些內容。首先,進行常識 腦補 注意 和.dsym成對出現,並且二者有相同的uui...

iOS 崩潰符號化

1.符號表是什麼?dsym檔案其實是乙個目錄,在子目錄中包含了乙個16進製制的儲存函式位址對映資訊的中轉檔案,所有debug的symbols都在這個檔案中 包括檔名 函式名 行號等 所以也稱之為除錯符號資訊檔案。注意 來檢查 那如何知道crash檔案的uuid呢?可以用 grep 那麼,問題就來了!...