使用 Flurry Crash Analytics 对 iOS 7 崩溃报告进行符号化答案

【问题标题】：Symbolicating an iOS 7 crash report using Flurry Crash Analytics使用 Flurry Crash Analytics 对 iOS 7 崩溃报告进行符号化
【发布时间】：2013-11-17 18:36:10
【问题描述】：

我最近为我的应用程序推送了 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> 符号，因为它肯定会帮助我修复导致这些崩溃的错误。谢谢！

【问题讨论】：

这里的 Flurry 崩溃日志有同样的问题，并且经历了许多相同的步骤。我没有在跟踪中看到“编辑”，但除了函数名称之外没有得到更多信息——我很想获得像从设备崩溃日志中获得的崩溃报告那样的行号。
经过多次试验和错误以及一些丑陋的黑客攻击......我能够象征一些崩溃报告，但这并不总是有效。我最终切换到 Crashlytics 以获取崩溃报告，同时保留 Flurry 进行统计。像魅力一样工作！

标签： ios xcode crash-reports flurry

【解决方案1】：

我注意到，为了能够将 Flurry 崩溃报告拖到 XCode Organizer，您需要：

将文件重命名为 .crash
在报告顶部添加事件标识符行。这看起来像一个 GUID，因此您可以输入任何独特的内容或 generate one online，例如

事件标识符：D1D6CA1F-EC87-4677-9366-401BE050B2C8
添加 iOS 和崩溃报告版本行（就在异常类型上方），例如

操作系统版本：iOS 7.1.1 (11D201)

报告版本：104

【讨论】：

太棒了，谢谢。巨大的帮助。我想出了第 1 步，但缺少第 2 步和第 3 步。现在完美运行。
非常感谢。有趣的是，我通过从另一个崩溃报告中复制第 2 步和第 3 步中的两行来猜测操作系统版本。另一项注意事项，我的日期是空白的。
stackoverflow.com/users/600362/tomi44g 可能想补充一下，如果文件被识别，直到那时，您会在顶部栏中看到“正在处理文件..”消息。
提供给OS Version 和Report Version 的值是否重要？

【解决方案2】：

<redacted> 是仅针对系统符号的 iOS 优化。
上传您的应用程序 dSYM 不会改变任何事情，因为它只包含应用程序符号，而不是所需 cpu 架构的 iOS 系统符号。
要在本地对这些符号进行符号化，您需要准确的系统符号或导致崩溃的 iOS 版本和架构。
使用atos 用您的应用程序二进制/dSYM 表示系统符号不起作用（如上所述）
只传入栈帧中的地址来获取符号，永远行不通，还需要传入对应二进制的加载地址（可以在二进制图片部分找到，行首地址）二进制文件）
在您的 atos 示例中，您正在尝试使用已在堆栈跟踪中显示正确符号的地址。
如果您有可用的符号，则将崩溃报告拖到 Xcode 管理器中应该已经符号化了报告，并且您不必执行手动步骤。
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 符号，并且手动步骤也不起作用。

【讨论】：

“我现在尝试简单地将这个文件拖到 Xcode 管理器中并导入设备日志。两者都没有做任何事情。”同样的问题...
如果 Xcode 符号化“什么都不做”，通常是因为以下原因： 1. 发生崩溃的特定 iOS 版本的 iOS 符号丢失； 2. 使用 Spotlight 无法找到崩溃的应用 dSYM 和应用二进制文件或两者之一找到但另一个没有

【解决方案3】：

这适用于我的混乱日志http://ipartymobile.com/how-to-find-your-bug-from-ios-crash-logs/ 不必在崩溃报告中添加任何内容，只需获取内存地址并插入这种格式“xcrun atos -arch armv7 -o MyApp 0x0000000”

【讨论】：