logo标签列表

使用Flurry Crash Analytics解析iOS 7崩溃报告中的符号化信息

iosxcodecrash-reportsflurry
11
我最近为我的应用程序推送了一个iOS 7更新，并使用启用崩溃报告的Flurry Analytics进行了实现。我最近注意到一些用户正在经历崩溃。使用Flurry，我可以检索出在我的应用程序崩溃时的堆栈跟踪以追踪问题。
好吧，我当然熟悉崩溃报告，并已经通过从iTunes Connect或邮件中获取它们并在Xcode中简单地符号化它们来修复错误。然而，我无法使用Flurry做到这一点。
我尝试过的：
在Flurry本身上查看堆栈跟踪时，我得到了以下结果： Flurry stack trace 正如您所看到的，许多行被完全符号化，其他行被符号化为<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 崩溃日志相同的问题，并经历了许多相同的步骤。在跟踪中没有看到"redacted"，但是只能得到函数名称而无法像从设备崩溃日志获取的崩溃报告一样得到行号，希望能够得到更多信息。 - mm2001
1
经过多次尝试和一些丑陋的hack，我终于能够符号化一些崩溃报告，但这并不总是有效。最终我选择了Crashlytics来处理崩溃报告，同时保留Flurry用于统计数据。现在一切都非常顺利！ - s1m0n
3个回答
10

我发现为了能够将Flurry崩溃报告拖到XCode组织器中，您需要:

  1. 将文件重命名为.crash

  2. 在报告顶部添加一个事故标识符行。这看起来像一个GUID，因此您可以放置任何唯一或在线生成一个，例如：

    事故标识符：D1D6CA1F-EC87-4677-9366-401BE050B2C8

  3. 添加iOS和Crash Report版本行(就在异常类型上面)，例如：

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

    报告版本：104

太棒了，谢谢。帮了大忙了。我已经解决了第一步，但是漏掉了第二步和第三步。现在完美运行。 - crgt
非常感谢。有趣的是，我通过复制另一个崩溃报告中步骤2和3的两行来猜测操作系统版本。还有一件值得注意的事情是，我的日期是空白的。 - SilentNot
可能需要在您的答案中添加以下内容：如果文件被识别，那么直到此时，您将在顶部栏中看到“正在处理文件…”的消息。 - SilentNot
提供给“操作系统版本”和“报告版本”的值是否重要？ - Crashalot
6
  1. <redacted> 是 iOS 系统符号的优化。
  2. 上传您的应用程序 dSYM 不会改变任何事情，因为它只包含应用程序符号，而不是所需 CPU 架构的 iOS 系统符号。
  3. 要在本地解析这些符号，您需要具有创建崩溃的确切系统符号或 iOS 版本和架构。
  4. 使用 atos 与您的应用程序二进制文件/dSYM 解析系统符号无效（如上所述）。
  5. 仅通过堆栈帧中传递地址来获取符号永远不起作用，您还需要传递相应二进制文件的加载地址（可以在二进制图像部分找到，在二进制文件行的第一个地址）。
  6. 在您的 atos 示例中，您正在尝试一个已经在堆栈跟踪中显示正确符号的地址。
  7. 将崩溃报告拖入 Xcode 组织器中，如果您有可用的符号，则应自动解析报告，您不必执行手动步骤。
  8. 看起来 Flurry 没有 iOS 符号可用于解析这些符号。

因此，libdispatch.dylib 库的 0x3a99ed7b 示例将是：

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

您的Mac上iOS符号的根路径是：~/Library/Developer/Xcode/iOS DeviceSupport/，每个iOS版本都有一个子目录。
因此，简单的解决方案是将崩溃报告拖放到Xcode组织者中的"设备日志"条目中，并希望您拥有所需的一切。如果这不能消除至少一些""字符串，则表示您缺少iOS符号，手动步骤也无法起作用。
4
我尝试将该文件拖入Xcode组织器并导入设备日志，但两种方法都没有效果。这里出现了同样的问题... - karmington
1
如果Xcode符号化“根本没有任何作用”，通常是由于以下原因：1.缺少发生崩溃的特定iOS版本的iOS符号；2.使用Spotlight找不到崩溃的应用程序dSYM和应用程序二进制文件，或者两者之一被找到但另一个未找到。 - Kerni
1
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接