iOS應用程序崩潰，符號化日誌不透明

我相信我正在查看正確的符號日誌，但請告訴我，如果情況並非如此。這是我從蘋果公司收到的崩潰日誌的摘錄，因爲在發佈時發生崩潰而被拒絕，而我一直無法複製它。iOS應用程序崩潰，符號化日誌不透明

我安裝了一個名爲Crashlytics的崩潰報告系統，該應用程序在審閱期間沒有收到崩潰報告，導致我相信崩潰發生在AppDelegate的初始化Crashlytics的didFinishLaunchingWithOptions之前。也就是說，Crashlytics只會在崩潰後重新打開應用程序時發送報告。所以蘋果的評論員可能已經經歷了崩潰，並沒有再次嘗試，可能的原因是我沒有Crashlytics報告。

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

Last Exception Backtrace: 
(0x181f9a084 0x1929ec0e4 0x180819674 0x100091318 0x100084fe4 0x100084098 0x18671d158 0x18671ce68 0x1867d0ee8 0x1869d1da8 0x186791938 0x18671e88c 0x1867906f8 0x10006187c 0x18678e5d0 0x1869a4de8 0x1869a7568 0x1869a5c00 0x18a171640 0x181f52360 0x181f51468 0x181f4fa8c 0x181e7d664 0x18678798c 0x186782984 0x100061c28 0x19305aa08) 

Thread 0 name: Dispatch queue: com.apple.main-thread 
Thread 0 Crashed: 
0 libsystem_kernel.dylib   0x0000000193172964 __kill + 8 
1 Luff       0x00000001001330dc 0x10005c000 + 880860 
2 libsystem_platform.dylib  0x0000000193208958 _sigtramp + 64 
3 libsystem_pthread.dylib   0x0000000193211224 pthread_kill + 108 
4 libsystem_c.dylib    0x00000001930eab14 abort + 108 
5 libc++abi.dylib     0x00000001921d1414 abort_message + 112 
6 libc++abi.dylib     0x00000001921f0b88 default_terminate_handler() + 300 
7 libobjc.A.dylib     0x00000001929ec3bc _objc_terminate() + 124 
8 libc++abi.dylib     0x00000001921edbb0 std::__terminate(void (*)()) + 12 
9 libc++abi.dylib     0x00000001921ed738 __cxa_rethrow + 140 
10 libobjc.A.dylib     0x00000001929ec290 objc_exception_rethrow + 40 
11 CoreFoundation     0x0000000181e7d710 CFRunLoopRunSpecific + 568 
12 UIKit       0x0000000186787988 -[UIApplication _run] + 548 
13 UIKit       0x0000000186782980 UIApplicationMain + 1484 
14 Luff       0x0000000100061c24 0x10005c000 + 23588 
15 libdyld.dylib     0x000000019305aa04 start + 0

來源

2014-10-10 Giles Van Gruisen

碰撞日誌是符號化的。 – TMob 2014-10-10 06:33:34

你有什麼是沒有完全符號。爲了使其完全符號化，即第14行和第1行中的函數名稱以及最後一個異常回溯，需要dSYM文件，這些文件在構建要提交的應用程序時已經生成並放置在與您的應用包相同的文件夾。如果您使用Xcode的存檔功能，我相信存檔中會包含dSYM。我說第1行和第14行，因爲那些是你的應用程序名稱（Luff）。

你需要做的是把崩潰報告，dSYM文件和應用程序文件（不是IPA）放在同一個文件夾中（我不確定該應用程序文件實際上是否需要Xcode符號化，因此請確保如果它不適用於崩潰報告和dSYM，它就在那裏）。然後，導入崩潰報告到Xcode組織者，然後點擊「重新符號」。

上面的內容因爲它現在是沒有dSYM的100％無用的，除非您可以以某種方式將報告中的地址映射到符號（函數，方法）。

另外，崩潰線程的堆棧跟蹤不在相關信息爲的地方。儘管如此，從經驗來看，我可以告訴你關於堆棧跟蹤的一些事情。第14行的符號很可能是您的main（）函數。沒有什麼特別的。

1到14之間的行顯示了一堆異常重新拋出和捕獲，即這不是導致崩潰的堆棧跟蹤，而是傳遞異常的堆棧跟蹤。既然你提到你有Crashlytics，我打賭第14行就是這樣。它說Luff而不是Crashlytics，因爲Crashlytics是嵌入到你的應用程序中的靜態庫。對於所有意圖和目的，iOS將其視爲您的應用的另一部分。我說它是Crashlytics的原因是當你捕捉崩潰時，導致崩潰（異常，信號等）的事情有時會被重新拋出，並最終到達你自己定製的崩潰報告代碼。

該相關信息是在Last Exception Backtrace地址你有上面。但要閱讀它，它必須用dSYM文件進行符號化。

就像你說的，Crashlytics不是實時的。用戶需要重新打開該應用程序。我知道這一切，因爲我正在致力於我自己的項目Crashional這是實時，只要有互聯網連接。

來源

2014-10-10 08:29:27 Roberto

感謝您幫助我意識到這並未完全符號化。我在翻譯第2行和第14行（相同的內存地址）時遇到了麻煩，但事實證明問題在於我使用的稱爲GPUImage的第三方框架。可悲的是它是一個我甚至沒有使用過的類的初始化器。提交了一份關於GH回購的問題。乾杯。 – 2014-10-10 16:54:58

很高興我能夠幫助。爲了澄清，第2行和第14行具有相同的基地址（0x10005c000），但不是相同的實際地址。基址不在十六進制（+880860和+23588）之後有一個偏移量。另外，如果它是正確的，請將其標記爲答案。 – Roberto 2014-10-14 16:11:00

您沒有通過Crashlytics獲得報告的一個可能原因是，審閱者在第一次啓動您的應用時可能在設備上禁用了互聯網。即使她再次打開它，它也不會將這次事故交還給Crashlytics。

來源

2015-03-31 17:36:34 Nathan

這不提供問題的答案。要批評或要求作者澄清，在他們的帖子下留下評論 - 你總是可以評論你自己的帖子，一旦你有足夠的[聲譽]（http://stackoverflow.com/help/whats-reputation），你會能夠[評論任何帖子]（http://stackoverflow.com/help/privileges/comment）。 – 2015-04-01 12:06:10

@ David'mArm'Ansermot，在「問題」中沒有問號。他只是表達了困惑，我提供了一個爲什麼會發生這種情況的原因 – Nathan 2015-04-24 17:03:22

iOS應用程序崩潰，符號化日誌不透明

回答

相關問題