使用Flurry Crash Analytics對iOS 7崩潰報告進行符號化

Question

我最近為我的應用推出了iOS 7更新，並實現了Flurry Analytics並啟用了崩潰報告。 我最近注意到一些用戶遇到了崩潰。 使用Flurry我可以在應用程序崩潰時檢索堆棧跟蹤以追蹤問題。
好吧，我當然熟悉崩潰報告，並且已經修復了之前使用它們的錯誤，從iTunes Connect或郵件中獲取它們並簡單地在Xcode中對它們進行符號化。 然而，我沒有成功使用Flurry做到這一點。

我嘗試了什么：
在Flurry上查看堆棧跟蹤時，這就是我得到的： 正如您所看到的，很多線條都是完美的象征，其他線條則被象征為<redacted> 。 一些研究告訴我Apple在iOS 6和7中剝離了很多調試符號。
我嘗試的第一件事是上傳我自己的dSYM文件。 Flurry報告已保存dSYM文件，並使用dSYM文件再次對崩潰報告進行符號化。 然而，堆棧跟蹤仍然與沒有dSYM完全相同。
沒問題，我想，我可以嘗試下載崩潰報告並使用Xcode對其進行符號化。 點擊下載為我提供了一個文件（沒有擴展名，所以我將其重命名為.crash ）：

Hardware Model:      iPhone3,1
Process:         RadioPlayer [2965]
Path:            /var/mobile/Applications/E4DD7DA6-4450-4538-A1E2-AE23139FAC10/RadioPlayer.app/RadioPlayer
Identifier:      *******
Version:         1.2.0
Code Type:       ARM
Parent Process:  launchd [1]

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0x548a000
Crashed Thread:  2

Thread 0:
0   libsystem_kernel.dylib              0x3aa67a8c _mach_msg_trap + 20
1   CoreFoundation                      0x3015e7cb <redacted> + 154
2   CoreFoundation                      0x3015cf37 <redacted> + 854
3   CoreFoundation                      0x300c7ce7 _CFRunLoopRunSpecific + 522
4   CoreFoundation                      0x300c7acb _CFRunLoopRunInMode + 106
5   GraphicsServices                    0x34da0283 _GSEventRunModal + 138
6   UIKit                               0x32969a41 _UIApplicationMain + 1136
7   RadioPlayer                         0x000dfb9b __mh_execute_header + 23451
8   libdyld.dylib                       0x3a9c3ab7 <redacted> + 2

Thread 1:
0   libsystem_kernel.dylib              0x3aa6783c _kevent64 + 24
1   libdispatch.dylib                   0x3a9a23f3 <redacted> + 38

Thread 2 Crashed:
0   vImage                              0x2f19d7dc <redacted> + 139
1   vImage                              0x2f1874ff _vImageFlatten_RGBA8888 + 378
2   vImage                              0x2f26e799 <redacted> + 40
3   vImage                              0x2f27d7c3 <redacted> + 674
4   vImage                              0x2f27d365 _vImageConvert_AnyToAny + 1300
5   ImageIO                             0x30efd9e7 <redacted> + 858
6   ImageIO                             0x30ef8c3b <redacted> + 2754
7   ImageIO                             0x30ef8173 <redacted> + 102
8   ImageIO                             0x30ef8057 _CGImageDestinationFinalize + 66
9   UIKit                               0x32a8a611 _UIImageJPEGRepresentation + 520
10  MediaPlayer                         0x31435319 -[MPMediaItemArtwork imageDataWithSize:atPlaybackTime:] + 36
11  MediaPlayer                         0x31435387 -[MPMediaItemArtwork albumImageDataWithSize:] + 42
12  MediaPlayer                         0x31494f0d -[MPNowPlayingInfoCenter _pushNowPlayingInfoAndRetry:] + 824
13  libdispatch.dylib                   0x3a99ed7b <redacted> + 10
14  libdispatch.dylib                   0x3a99f2f3 <redacted> + 378
15  libdispatch.dylib                   0x3a99f75b <redacted> + 38
16  libdispatch.dylib                   0x3a9b18f9 <redacted> + 76
17  libdispatch.dylib                   0x3a9b1b79 <redacted> + 56
18  libsystem_pthread.dylib             0x3aae0dbf __pthread_wqthread + 298
19  libsystem_pthread.dylib             0x3aae0c84 _start_wqthread + 8


// The file continues like this listing the other threads and overview of binary images.
// I however didn't paste that part here since I don't think it's useful.

我現在嘗試將這個文件拖放到Xcode組織器並導入設備日志。 兩者都沒有做到。 列表中沒有出現新設備日志或其他任何內容。
下一步：嘗試使用atos手動表示崩潰日志。 我將dSYM的內容復制到工作目錄等，然后嘗試了這個命令

xcrun atos -arch armv7 -o RadioPlayer 0x31435387`

這返回0x31435387 。 我嘗試了一些其他內存地址，輸出每次只是內存地址本身。

有人可以幫我解決這個問題嗎？ 我真的很想象征這些<redacted>符號，因為它肯定會幫助我修復導致這些崩潰的錯誤。 謝謝！

Answer 1

我注意到為了能夠將Flurry崩潰報告拖到XCode Organizer，您需要：

1. 將文件重命名為.crash

2. 在報告頂部添加事件標識符行。 這看起來像一個GUID，因此您可以放置​​任何唯一的或在線生成一個 ，例如

   事件標識符：D1D6CA1F-EC87-4677-9366-401BE050B2C8

3. 添加iOS和崩潰報告版本行（在例外類型上方），例如

   操作系統版本：iOS 7.1.1（11D201）

   報告版本：104

Answer 2

1. <redacted>是僅針對系統符號的iOS優化。
2. 上傳您的應用程序dSYM不會改變任何東西，因為它只包含應用程序符號，而不是所需cpu體系結構的iOS系統符號。
3. 要在本地表示符號，您需要具有確切的系統符號或創建崩潰的iOS版本和體系結構。
4. 使用atos到symbolicate系統符號與您的應用程序二進制/的dSYM不起作用（如上所述）
5. 通過僅傳遞堆棧幀中的地址來獲取符號，從不起作用，您還需要傳遞相應二進制文件的加載地址（可以在二進制圖像部分中找到，二進制文件行中的第一個地址）
6. 在您的atos示例中，您正在嘗試一個已在堆棧跟蹤中顯示正確符號的地址。
7. 如果您有可用的符號，則將崩潰報告拖動到Xcode組織器中應該已經對報告進行了符號化，您不必執行手動步驟。
8. 看起來Flurry的服務器上沒有iOS符號來自行解析這些符號。

因此，對於一個例子0x3a99ed7b的的libdispatch.dylib庫將是：

xcrun atos -arch armv7 -o PathToLibrary -l LoadAddressOfLibrary 0x3a99ed7b

Mac上iOS符號的根路徑是：〜/ Library / Developer / Xcode / iOS DeviceSupport /`，每個iOS版本都有一個子目錄。

因此，簡單的解決方案是：將崩潰報告拖到Xcode組織器的“ Device Logs條目中，並希望您擁有所需的一切。 如果這不能刪除至少一些<redacted>字符串，則缺少iOS符號，手動步驟也不起作用。

Answer 3

這對我的亂跑日志起作用http://ipartymobile.com/how-to-find-your-bug-from-ios-crash-logs/沒有為崩潰報告添加任何內容，只需占用內存地址並插入格式為“xcrun atos -arch armv7 -o MyApp 0x0000000”