iOS Crash日誌

時間 2019-11-19

標籤 ios crash 日誌欄目 iOS 简体版

原文原文鏈接

Understanding Crash Reports on iPhone OShtml

https://developer.apple.com/videos/wwdc/2010/?id=317ios

http://www.cnblogs.com/smileEvday/p/Crash1.html數組

http://www.cocoachina.com/industry/20130725/6677.html xcode

http://www.cnblogs.com/tiechui/p/3820044.html (http://developer.apple.com/library/ios/#technotes/tn2151/_index.html)網絡

　　當一個應用程序在一臺iOS 設備上崩潰時，一份「崩潰報告」將在該設備上次建立並存儲起來。崩潰報告描述應用程序是在何種條件下崩潰的，大部分狀況下包含一份當前正在運行線程的完整的堆棧跟蹤。架構

產生崩潰日誌的緣由app

應用違反操做系統規則，包括在啓動、恢復、掛起、退出時watchdog超時、用戶強制退出和低內存終止等。
應用中有Bug

　　從多任務窗口中終止一個暫停的應用程序不會產生崩潰日誌。一旦一個應用被暫停，它有資格被iOS在任什麼時候間終止，所以不會產生崩潰日誌。框架

Crash獲取途徑

本機經過Xcode的Devices窗口獲取某個設備的崩潰日誌
設備與電腦上的iTunes Store同步後，會將崩潰日誌保存在電腦上。根據電腦操做系統的不一樣，崩潰日誌將保存在如下位置:
- Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/
- Windows XP: C:/Documents and Settings/Application Data/Apple Computer/Logs/CrashReporte/rMobileDevice/
- Windows Vista以上: C:/Users/用戶名/AppData/Roaming/Apple Computer/Logs/CrashReporter/MobileDevice/
應用提交到App Store後，可經過itunes connect後臺獲取到用戶上報的Crash日誌。
有不少優秀的第三方Crash收集系統大大的方便了咱們收集Crash，甚至還帶了符號化Crash日誌的功能。比較經常使用的有Crashlytics，Flurry等。

Crash文件結構

1.Process Information

Incident Identifier: 66AFBBF0-7ACB-4319-97C7-6F44E09FF9EB         //崩潰報告的惟一標識符
CrashReporter Key:   97aec51145730a778c0d1cfdfc17c1b8c86ba4c5     //設備標識相對應的惟一鍵值(並不是真正的設備的UDID，爲保護隱私iOS6之後已沒法獲取)
Hardware Model:      iPad5,3                                      //發生Crash的設備類型
Process:             XXXXClient [407]      　　　　　　　　　　　    //Crash的進程名稱，一般都是咱們的App的名字, []裏面是當時進程的ID
Path:                /private/var/mobile/Containers/Bundle/Application/0380D606-3A40-4633-A1B2-7E1F3E3D4FCA/XXXXClient.app/XXXXClient   
　　　　　　　　　　　　//可執行程序在手機上的存儲位置，注意路徑時到x.app/x，x.app實際上是做爲一個Bundle的，真正的可執行文件實際上是Bundle裏面的x
Identifier:          com.xxxx.myapp                               //App的Indentifier，一般爲「com.xxx.yyy」
Version:             1 (1.0.0)                                    //App的版本號，由Info.plist中
Code Type:           ARM-64 (Native)　　　　　　　　　　　　　　　　   //App的CPU架構
Parent Process:      launchd [1]                                  //當前進程的父進程，因爲iOS中App一般都是單進程的，通常父進程都是launchdCFBundleShortVersionString +CFBundleVersion

2.Basic Information

Date/Time:           2016-02-19 00:34:43.449 -0800                //Crash發生的時間
Launch Time:         2016-02-19 00:34:43.399 -0800               
OS Version:          iOS 8.4 (12H143)                             //系統版本，括號內的數字表明的時Bulid號
Report Version:      105                                          //Crash日誌的格式

3.Exception

Exception Type:  　　EXC_CRASH (SIGABRT)                             //異常類型
Exception Subtype:                                                  //v104
Exception Codes: 　　0x0000000000000000, 0x0000000000000000          //v105
Triggered by Thread: 0                                              //v105
Crashed Thread                                                      //v104

4.Thread Backtrace

發生Crash的線程的Crash調用棧，從上到下分別表明調用順序，最上面的一個表示拋出異常的位置，依次往下能夠看到API的調用順序。ide

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
//編號  二進制庫名                        調用方法的地址       基本地址 + 偏移
0   libsystem_kernel.dylib        	0x0000000194b3b270 __pthread_kill + 8
1   libsystem_pthread.dylib       	0x0000000194bd916c pthread_kill + 108
2   libsystem_c.dylib             	0x0000000194ab2b14 abort + 108
3   ...g_rt.asan_ios_dynamic.dylib	0x00000001032756d0 0x103224000 + 333520
4   ...g_rt.asan_ios_dynamic.dylib	0x000000010326955c 0x103224000 + 283996
5   ...g_rt.asan_ios_dynamic.dylib	0x000000010326cf28 0x103224000 + 298792
6   ...g_rt.asan_ios_dynamic.dylib	0x0000000103269640 0x103224000 + 284224
7   ...g_rt.asan_ios_dynamic.dylib	0x000000010326d0e8 0x103224000 + 299240
8   ...g_rt.asan_ios_dynamic.dylib	0x000000010325ef50 0x103224000 + 241488
9   ...g_rt.asan_ios_dynamic.dylib	0x0000000103268d18 0x103224000 + 281880
10  dyld                          	0x00000001200b9234 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 256
11  dyld                          	0x00000001200b93ec ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 32
12  dyld                          	0x00000001200b5688 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 328
13  dyld                          	0x00000001200b561c ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 220
14  dyld                          	0x00000001200b54d8 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 136
15  dyld                          	0x00000001200b57a0 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 80
16  dyld                          	0x00000001200aa150 dyld::initializeMainExecutable() + 196
17  dyld                          	0x00000001200ad8bc dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2664
18  dyld                          	0x00000001200a9040 _dyld_start + 64

5.Thread State

Crash時發生時刻，線程的狀態（寄存器中的值）函數

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0x0000000000010000
    x4: 0x000000000000027b   x5: 0x0000000000000000   x6: 0x0000000000000000   x7: 0x0000000000000250
    x8: 0x0000000008000000   x9: 0x0000000004000000  x10: 0x0000000000000000  x11: 0x0000000000000018
   x12: 0x0000000000000001  x13: 0x0000000000062aa8  x14: 0x0000000000000015  x15: 0x0000000000000000
   x16: 0x0000000000000148  x17: 0x0000000000000000  x18: 0x0000000000000000  x19: 0x0000000000000006
   x20: 0x0000000198ae4310  x21: 0x0000000103280963  x22: 0x0000000000000000  x23: 0x0000000000000000
   x24: 0x0000000000000093  x25: 0x000000016fd182d8  x26: 0x00000001200d8d11  x27: 0x000000010328c000
   x28: 0x00000001032243d0  fp: 0x000000016fd17920   lr: 0x0000000194bd9170
    sp: 0x000000016fd17900   pc: 0x0000000194b3b270 cpsr: 0x00000000

6.Binary Images

Crash時刻App加載的全部的庫，其中第一行是Crash發生時咱們App可執行文件的信息，能夠看出爲armv7，可執行文件的包得uuid位c0f……cd65，解析Crash的時候dsym文件的uuid必須和這個同樣才能完成Crash的符號化解析。

Binary Images:
0x1000e4000 - 0x101fdffff XXXClient arm64  <aa8ef7e9f9c43c7c87f4f75cf266d479> /var/mobile/Containers/Bundle/Application/0380D606-3A40-4633-A1B2-7E1F3E3D4FCA/XXXXClient.app/XXXXClient
0x103224000 - 0x103287fff libclang_rt.asan_ios_dynamic.dylib arm64  <c51061e5b8443a8e9b6c2b76628b4b95> /var/mobile/Containers/Bundle/Application/0380D606-3A40-4633-A1B2-7E1F3E3D4FCA/XXXX.app/Frameworks/libclang_rt.asan_ios_dynamic.dylib
0x1200a8000 - 0x1200cffff dyld arm64  <de589e6153453237a6cf724cb236d83c> /usr/lib/dyld
0x1810ac000 - 0x181240fff AVFoundation arm64  <b9c4b32ba43a3a798c4adcaad3608f52> /System/Library/Frameworks/AVFoundation.framework/AVFoundation
0x181244000 - 0x1812a8fff libAVFAudio.dylib arm64  <6667f63f0f1635668dc941d6b79062e1> /System/Library/Frameworks/AVFoundation.framework/libAVFAudio.dylib
0x194bf0000 - 0x194bf5fff libunwind.dylib arm64  <8b87982b31ad3569a95e75457cadba3e> /usr/lib/system/libunwind.dylib
0x194bf8000 - 0x194c1bfff libxpc.dylib arm64  <c9f3c08a8a3b3849a905d24911240853> /usr/lib/system/libxpc.dylib

符號化

包含堆棧跟蹤的崩潰報告須要先進行符號化（symbolicated）才能夠進行分析。符號化的過程是將內存地址替換爲便於人們閱讀的函數名稱和行號。假如你經過Xcode的Organizer窗口獲取崩潰日誌，那麼該報告將在幾秒鐘後自動進行符號化。不然你須要將.crash文件導入到Xcode的Organizer進行符號化。

//符號化前
6  Rage Masters   0x0001625c        0x2a000 + 3003

//符號化後
6  Rage Masters   0x0001625c        -[RMAppDelegate application:didFinishLaunchingWithOptions:]  (RMAppDelegate.m:35)

符號化與歸檔

　　Xcode符號化崩潰日誌時，須要訪問與App Store上對應的應用二進制文件以及生成二進制文件時產生的 .dSYM 文件。必需徹底匹配才行。不然，日誌將沒法被徹底符號化。因此，保留每一個分發給用戶的編譯版本很是重要。提交應用前進行歸檔時，Xcode將保存應用的二進制文件。能夠在Xcode Organizer的Archives標籤欄下找到全部已歸檔的應用文件。在發現崩潰日誌時，若是有相匹配的.dSYM文件和應用二進制文件，Xcode會自動對崩潰日誌進行符號化。若是你換到別的電腦或建立新的帳戶，務必將全部二進制文件移動到正確的位置，使Xcode能找到它們。

（注意: 你必需同時保留應用二進制文件和.dSYM文件才能將崩潰日誌完整符號化。每次提交到iTunes Connect的構建都必需歸檔。.dSYM文件和二進制文件是特定綁定於每一次構建和後續構建的，即便來自相同的源代碼文件，每一次構建也與其餘構建不一樣，不能相互替換。若是你使用Build 和 Archive 命令,這些文件會自動放在適當位置。若是不是使用Build 和 Archive命令，放在Spotlight可以搜索到的位置（好比Home目錄）便可。）

在崩潰報告中最使人感興趣的部分是在你的應用程序執行終止時的堆棧跟蹤。這個跟蹤和你在調試器中中止執行時的相似，但遺憾的是這裏沒有提供被認爲是符號的方法或函數的名稱。取而代之的是16位的內存地址和它所指向的你的應用程序或系統框架的可執行代碼。你須要將這些地址映射到符號中。崩潰日誌在輸出時並不包含土豪信息，你須要在你分析日誌前進行符號化處理。

符號化——將堆棧跟蹤地址轉化爲源代碼方法名稱及行號——須要上次到蘋果應用商店的應用程序的二進制文件以及構建二進制文件時產生的.dSYM文件。這些必須是精確匹配的，不然你的報告將不能完整地符號化。基本要求你保持每一個分發給用戶（忽略那些分發的細節）的構建和它的.dSYM是一致的。

注意：

你必須保存應用程序的二進制文件和.dSYM文件以便於完整地符號化崩潰日誌。你應該打包每個你所提交到iTunes Connect中的構建。.dSYM文件和應用程序的二進制文件應該綁定到一塊兒，無論是基礎版本的構建仍是後續版本的構建。即使是相同的源代碼，不一樣構建的文件也不會弄混。假如你使用「構建並打包」命令，那麼它們將會被自動放置到一個合適的位置。雖然任何位置均可以用Spotlight搜索到。

Xcode的「打包（Archive）」命令使保持二進制文件和.dSYM匹配變得很簡單，當你使用打包命令（經過點擊產品（「Product」）-）打包（Archive）或是按下Shift+Command+B），Xode將會把應用程序的二進制文件及包含符號信息的.dSYM文件收集到一塊兒，並存儲到你的主目錄文件夾下的一個合適位置。你能夠在Xcode中的Organizer下的「已打包（Archived）」中知道你所打包的全部應用程序。Xcode在符號化崩潰日誌時會自動尋找打包的應用程序，在確認你要的發佈應用程序和.dSYM文件匹配的狀況下，你能夠將它們打包，直接提交到ITunes Connect。

若是Xcode擁有產生崩潰日誌的應用程序的二進制代碼和.dSYM文件，那麼它將自動進行符號化。Xcode Organizer符號化所須要提供的是崩潰日誌及相應的二進制文件和.dSYM文件。打開Xcode Organizer，選擇「設備（Devices）」選選看，選擇邊欄頂部「文庫（LIBRARY）」下的「設備日誌（Device Logs）」，點擊導入按鈕，選擇須要符號化的.crash文件，當這些步驟完成後，Xcode將自動符號化崩潰日誌並顯示結果。

常見Crash類型

0x8badf00d(eat bad food) Watchdog timeout

緊接着下面會有一段描述：

Application Specific Information：

com.xxx.yyy　　 failed to resume in time

該應用程序花了太長的時間加載，終止或響應系統時間。若是你沒有把須要花費時間比較長的操做(如網絡訪問）放在後臺線程上就很容易發生這種狀況。

從iOS 4.x開始，退出應用時，應用不會當即終止，而是退到後臺。可是，若是你的應用響應不夠快，操做系統有可能會終止你的應用，併產生一個崩潰日誌。下面這些方法，應用只有有限的時間去完成處理。若是花費時間太長，操做系統將終止應用。

application:didFinishLaunchingWithOptions:

applicationWillResignActive:

applicationDidEnterBackground:

applicationWillEnterForeground:

applicationDidBecomeActive:

applicationWillTerminate:

後面的分號說明只有一個參數

對於此類Crash，咱們應該去審視本身App初始化時作的事情是否正確，是否在主線程請求了網絡，或者其餘耗時的事情卡住了正常初始化流程。

一般系統容許一個App從啓動到能夠相應用戶事件的時間最多爲5S，若是超過了5S，App就會被系統終止掉。在Launch，resume，suspend，quit時都會有相應的時間要求。在Highlight Thread裏面咱們能夠看到被終止時調用到的位置，xxxAppDelegate加上行號。

PS. 在鏈接Xcode調試時爲了便於調試，系統會暫時禁用掉Watchdog，因此此類問題的發現須要使用正常的啓動模式。

0xdeadfa11(dead fall) User force-quit

　　這個強制退出跟咱們平時所說的kill掉後臺任務操做還不太同樣，一般在程序bug形成系統沒法響應時能夠採用長按電源鍵，當屏幕出現關機確認畫面時按下Home鍵便可關閉當前程序。

　　雙擊Home按鈕後，你將看到運行過的全部應用。那些應用不必定是正在運行，也不必定是被掛起。一般，用戶點擊Home按鈕時，應用將在後臺保留約10分鐘，而後操做系統自動將其終止。因此雙擊Home按鈕顯示的應用列表只是代表那是一系列過去打開過的應用。刪除那些應用的圖標不會產生任何崩潰日誌。

0xbaaaaaad

該Crash log並不是一個真正的Crash，它僅僅只是包含了整個系統某一時刻的運行狀態。一般能夠經過同時按Home鍵和音量鍵，可能因爲用戶不當心觸發

0xbad22222

當VOIP程序在後臺太過頻繁的激活時，系統可能會終止此類程序

0xc00010ff

程序執行大量耗費CPU和GPU的運算，致使設備過熱，觸發系統過熱保護被系統終止

0xdead10cc

程序退到後臺時還佔用系統資源，如通信錄被系統終止

Low Memory termination

跟通常的Crash結構不太同樣，一般有Free pages，Wired Pages，Purgeable pages，largest process 組成，同時會列出當前時刻系統運行全部進程的信息。IOS 內存警告 Memory warning level

App在運行過程當中，系統內存緊張時一般會先發警告（子類化UIViewController時,你或許已經注意到didReceiveMemoryWarning方法），同時把後臺掛起的程序終止掉，最終若是仍是內存不夠的話就會終止掉當前前臺的進程。

當接受到內存警告的過後，咱們應該釋放盡量多的內存，Crash其實也能夠看作是對App的一種保護。

當監測到內存不足時，iOS的虛擬內存系統依靠應用程序間的合做來釋放內存。內存不足的通知被髮送到全部正在運行的應用程序，並做爲內存釋放的請求來進行處理，以指望下降所使用的內存總量。若是內存的壓力始終存在，那麼系統可能會終止一些後臺進程來下降內存壓力。若是能夠釋放足夠多的內存，那麼你的應用程序將繼續運行而不會產生崩潰報告。若是不能夠，那麼你的程序將被iOS終止，由於此時已沒有足夠的內存來知足應用程序的需求，一分內存不足的報告將被產生並存儲在設備中。

內存不足報告與其餘崩潰報告的不一樣之處在於它裏面沒有應用程序的堆棧跟蹤。每一個進程的內存使用量依據內存頁面的數量進行報告，每一個內存頁面量的大小爲4KB。你將會看到「拋棄（jettisoned）」緊跟在iOS爲了釋放內存而終止的進程名稱後。若是你看到它緊跟在你的應用程序名稱後面，那麼能夠肯定這個應用由於使用了太多的內存而被終止。不然，應該不是內存壓力引發的崩潰。你能夠經過查看.crash文件（下一節中進行描述）獲取更多信息。

當你看到一個內存不足報告時，你更應該研究一下你使用內存的方式和你對內存不足警告的處理方式，而不是去關心在程序終止時你的哪一部分代碼被執行了。內存分配幫助（Memory Allocations Help）列舉了如何使用泄露工具（Leaks Instrument）來發現內存泄露，以及如何使用分配工具（Allocations Instrument's）的標記堆功能來避免被拋棄的內存。內存使用性能指導方案（Memory Usage Performance Guidelines）討論了像其餘內存使用祕訣同樣的適當的方案來響應內存不足通知。同時也建議你看一下WWSC2010中的關於使用工具進行高效內存分析的視頻（Advanced Memory Analysis with Instruments）。

　　泄露和分配工具不能跟蹤顯存。你須要使用VM Tracker工具（包含在分配工具模板中）來運行你的應用以便觀察顯存的使用狀況。VM Tracker默認是禁用的。爲了在你的應用程序使用VM Tracker，請點擊工具，選中「自動快照Automatic Snapshotting」標誌或者手工按下「獲取快照（Snapshot Now）」按鈕。

當應用發生低內存閃退時，你必需看看應用中內存使用的方式，以及是如何處理低內存警告的。你可使用Instruments工具中使用Allocations 和 Leaks來發現內存分配問題和內存泄漏問題。若是你不知道如何利用 Instruments 檢查內存問題，能夠看看這個教程。

還有，別忘記虛擬內存！ Instruments工具的Leaks 和 Allocations 不能跟蹤顯存使用狀況。必需使用 VM Tracker 才能查看顯存使用狀況。

VM Tracker 默認是關閉的。打開Instrument,手動選中Automatic Snapshotting 標誌或者按下Snapshot Now 按鈕。

當內存使用達到必定程度時，操做系統將發出一個 UIApplicationDidReceiveMemoryWarningNotification 通知。同時,調用 didReceiveMemoryWarning 方法。

此時，爲了讓應用繼續正常運行，操做系統開始終止在後臺的其餘應用以釋放一些內存。全部後臺應用被終止後，若是你的應用還須要更多內存，操做系統會將你的應用也終止掉，併產生一個崩潰日誌。而在這種狀況下被終止的後臺應用，不會產生崩潰日誌。

在極短期內分配一大塊內存將給系統內存帶來巨大負擔。這樣，也會產生內存警告的通知。

低內存崩潰日誌上沒有應用線程的堆棧回溯。相反，上面顯示的是之內存頁數爲單位的各進程內存使用量。

被iOS因釋放內存頁終止的進程名稱後面你會看到jettisoned 字樣。若是看到它出如今你的應用名稱後面，說明你的應用因使用太多內存而被終止了。

Free Pages 可用內存頁數（每頁大約4KB）

Purgeable pages 可被清除重用的內存

Largest process 閃退時使用大部份內存的應用

Processes顯示了閃退時各進程列表，還包含內存使用量。包含進程名 (第一列), 進程惟一標識符(第二名), 進程使用的內存頁數(第三列)。最後一列是每一個應用的狀態。一般，發生閃退的應用的狀態是 frontmost。

SpringBoard 進程是顯示主屏幕的應用

Crash due to bugs

常見Exception Type

EXC_BAD_ACCESS 一般用於訪問了不改訪問的內存致使。通常EXC_BAD_ACCESS後面的"()"還會帶有補充信息。

SIGSEGV: 一般因爲重複釋放對象致使，這種類型在切換了ARC之後應該已經不多見到了。
SIGABRT: 收到Abort信號退出，一般Foundation庫中的容器爲了保護狀態正常會作一些檢測，例如插入nil到數組中等會遇到此類錯誤。
SEGV:（Segmentation Violation），表明無效內存地址，好比空指針，未初始化指針，棧溢出等；
SIGBUS：總線錯誤，與 SIGSEGV 不一樣的是，SIGSEGV 訪問的是無效地址，而 SIGBUS 訪問的是有效地址，但總線訪問異常(如地址對齊問題)
SIGILL：嘗試執行非法的指令，可能不被識別或者沒有權限

異常代碼是SIGABRT。一般, SIGABRT 異常是因爲某個對象接收到未實現的消息引發的。或者，用簡單的話說，在某個對象上調用了不存在的方法。

這種狀況通常不會發生，由於A對象調用了B方法，若是B方法不存在，編譯器會報錯。可是，若是你是使用selector間接調用方法的，編譯器則沒法檢測對象是否存在該方法了。

EXC_BAD_INSTRUCTION

　　此類異常一般因爲線程執行非法指令致使

EXC_ARITHMETIC

　　除零錯誤會拋出此類異常

------------------------------

AddressSenitizer引起的崩潰

iOS9能夠正常啓動。

iOS9如下版本設備鏈接調試能夠正確啓動，斷開調試後啓動崩潰，日誌以下

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x0000000197747270 __pthread_kill + 8
1   libsystem_pthread.dylib         0x00000001977e516c pthread_kill + 108
2   libsystem_c.dylib               0x00000001976beb14 abort + 108
3   ...g_rt.asan_ios_dynamic.dylib  0x00000001019d56d0 0x101984000 + 333520
4   ...g_rt.asan_ios_dynamic.dylib  0x00000001019c955c 0x101984000 + 283996
5   ...g_rt.asan_ios_dynamic.dylib  0x00000001019ccf28 0x101984000 + 298792
6   ...g_rt.asan_ios_dynamic.dylib  0x00000001019c9640 0x101984000 + 284224
7   ...g_rt.asan_ios_dynamic.dylib  0x00000001019cd0e8 0x101984000 + 299240
8   ...g_rt.asan_ios_dynamic.dylib  0x00000001019bef50 0x101984000 + 241488
9   ...g_rt.asan_ios_dynamic.dylib  0x00000001019c8d18 0x101984000 + 281880
10  dyld                            0x0000000120095234 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 256
11  dyld                            0x00000001200953ec ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 32
12  dyld                            0x0000000120091688 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 328
13  dyld                            0x000000012009161c ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 220
14  dyld                            0x00000001200914d8 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 136
15  dyld                            0x00000001200917a0 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 80
16  dyld                            0x0000000120086150 dyld::initializeMainExecutable() + 196
17  dyld                            0x00000001200898bc dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2664
18  dyld                            0x0000000120085040 _dyld_start + 64