不同的崩潰報告，但同樣的崩潰？

Question

我瞭解一下這兩個崩潰報告一些事情的一個問題，我從蘋果公司獲得：

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0x617401fa 
Crashed Thread: 0 
0 app      0x0017c0ca Json::parse(int, JSON_value_struct const*) + 378 
1 app      0x0017bf46 Json::parse(void*, int, JSON_value_struct const*) + 2 
2 app      0x001302d2 JSON_parser_char + 2070 
3 app      0x0017bb58 Json::parse(std::string const&) + 356 
4 app      0x0008e682 NotificationData::ProcessNotifications(std::vector<UserEvent, std::allocator<UserEvent> >&) + 1062 
5 app      0x00106aea SMS::CheckNotifications() + 106 
6 app      0x001073dc SMS::update(Rex::TimeData const&) + 936 
7 app      0x00192c7e SceneManager::updateTick(TimeData const&) + 314 
8 app      0x001685ae Core::onRender(TimeData const&) + 522 

和

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0xffff0202 
Crashed Thread: 0 
0 app      0x0017c0ca 0x1000 + 1552586 
1 app      0x0017bf46 0x1000 + 1552198 
2 app      0x001302d2 0x1000 + 1241810 
3 app      0x0017bb58 0x1000 + 1551192 
4 app      0x0008e682 0x1000 + 579202 
5 app      0x00106aea 0x1000 + 1071850 
6 app      0x001073dc 0x1000 + 1074140 
7 app      0x00192c7e 0x1000 + 1645694 
8 app      0x001685ae 0x1000 + 1471918 

一些事實第一：第一個是說發生的40％時間和第二次35％。如果這是真的，那對我來說是件好事。

我根據我瞭解這個東西的理由是，它們是同一個，因爲功能的內存不會忽略是完全一樣的，只是KERN_INVALID_ADDRESS在0x617401fa和KERN_INVALID_ADDRESS在0xffff0202不同，這可以預期，因爲該功能是

我第一問題是爲什麼在崩潰報告的某個時候symbolicated（或部分symbolicated）等次書面方式一些腐敗的文件在磁盤上不？ （我剛剛進入分析它們和我們的編譯系統是不節能的每個產生的dSYM文件建立，所以我不能做symbolicating第二個多大的事）

的第二一個怎麼可能一個崩潰報告來自用戶的象徵意義？當我查看該項目時，發佈版本的設置如下所示：對於ALL_BUILDS，GCC_GENERATE_DEBUGGING_SYMBOLS設置爲NO，並且目標應用程序級別debug_information設置爲帶有dSYM文件的矮人，並生成調試符號設置爲編號（側面問題：使用這些設置構建時，不會生成dSYM，但如果從cMake（...）將GCC_GENERATE_DEBUGGING_SYMBOLS設置爲true，則生成dSYM。由於我讀取目標級別設置時會覆蓋生成級別設置）

對不起，這是我的第一個帖子。

Answer 1

關於事實：它獲得iTunes的40％的崩潰！到目前爲止，並不是所有的應用崩潰。 iTunes Connect僅顯示來自設備的崩潰，用戶在設置設備時確實批准發送匿名使用數據（因爲iOS 5可以稍後在設置應用程序中更改深度）。而且只有一小部分用戶可以啓用，因爲他們不想被追蹤。在iOS5系統上，崩潰報告也僅在設備與iTunes同步後纔會發送。

所以簡而言之：iTunes Connect上的崩潰報告並不能爲您提供崩潰報告的真實視圖。這裏有一個關於Camera +開發人員這個事實的博客文章：http://taptaptap.com/blog/cameraplus-2-3-1-available-attack-of-the-crashinator/

這兩個崩潰報告是相同的，你是對的。

問題1：設備上的所有崩潰報告都發送給Apple，但未進行符號化處理。象徵性發生在Apple的服務器上。而且，由於他們仍然收到大量的崩潰報告（即使只有真正發生的一小部分），他們只是象徵性地爲每個組報告一個報告，以減少服務器上的負載。

由於存儲器地址是相同的，所以第二個符號表示的結果與第一個符號相同。

問題2：如果蘋果未從中剝離，蘋果會使用來自應用程序二進制文件的符號。他們不使用dSYM，也不使用或不需要它。這種方式的缺點：你沒有得到行號，二進制可執行文件大30-50％。相關的版本設置是COPY_PHASE_STRIP。我認爲你的情況設置爲NO。

關於設置級別：在Xcode中選擇項目，然後選擇目標，查看版本設置不是Combined而是Levels。最左側的值（已解決的列）是正在使用的值。如果您在.xcconfig文件中使用構建設置，則通常會在項目級別針對每個構建配置進行設置，如果設置不同，則目標會覆蓋這些設置。