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

Symbolicating an iOS 7 crash report using Flurry Crash Analytics

提问by s1m0n

I recently pushed an iOS 7 update for my application and implemented Flurry Analytics with crash reporting enabled. I recently noticed some users are experiencing crashes. Using Flurry I can retrieve the stack trace at the moment my app crashed to track down the issue.
Well, I'm certainly familiar with crash reports and already fixed bugs using them before by getting them from iTunes Connect or mail and simply symbolicating them in Xcode. I however don't succeed at doing that using Flurry.

我最近为我的应用程序推送了 iOS 7 更新，并实现了启用崩溃报告的 Flurry Analytics。我最近注意到一些用户遇到了崩溃。使用 Flurry，我可以在我的应用程序崩溃时检索堆栈跟踪以追踪问题。
好吧，我当然熟悉崩溃报告，并且之前已经通过从 iTunes Connect 或邮件获取它们并在 Xcode 中简单地符号化它们来修复错误。然而，我没有成功地使用 Flurry 做到这一点。

What I tried:
When viewing the stack trace on Flurry itself, this is what I get: As you can see, a lot of lines are perfectly symbolicated, others are symbolicated to <redacted>. Some research learned me that Apple stripped a lot of debug symbols in iOS 6 and 7.
First thing I tried was uploading my own dSYM file. Flurry reported the dSYM file was saved and crash reports were symbolicated again using the dSYM file. The stack trace was however still exactly the same as without a dSYM.
No problem, I thought, I could just try to download the crash report and symbolicate it using Xcode. Clicking on downloadgives me a file (without extension, so I renamed it to .crash) with this content:

我尝试过的：
在 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.

I now tried both simply dragging this file into the Xcode organizer and importing device logs. Both did simply nothing. There didn't appear a new device log in the list or anything else.
Next step: trying to symbolicate the crash log manually using atos. I copied the content of the dSYM to the working directory etc and then tried this command

我现在尝试简单地将此文件拖入 Xcode 管理器并导入设备日志。两者都没有做任何事情。列表中没有出现新设备日志或其他任何内容。
下一步：尝试使用atos. 我将 dSYM 的内容复制到工作目录等，然后尝试使用此命令

xcrun atos -arch armv7 -o RadioPlayer 0x31435387`

This returned 0x31435387. I tried some other memory addresses and the output was each time just the memory address itself.

这回来了0x31435387。我尝试了一些其他内存地址，每次输出只是内存地址本身。

Can anybody please help me with this issue? I would really love to symbolicate these <redacted>symbols since it would certainly help me to fix the bug that leads to those crashes. Thanks!

有人可以帮我解决这个问题吗？我真的很想象征这些<redacted>符号，因为它肯定会帮助我修复导致这些崩溃的错误。谢谢！

回答by tomi44g

I noticed that in order to be able to drag the Flurry crash report to XCode Organizer you need to:

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

1. Rename the file to .crash

2. Add an incident identifier line at the top of the report. This looks like a GUID so you can put anything unique or generate one online, e.g.

   Incident Identifier: D1D6CA1F-EC87-4677-9366-401BE050B2C8

3. Add iOS and Crash Report version lines (just above the Exception Type), e.g.

   OS Version: iOS 7.1.1 (11D201)

   Report Version: 104

1. 将文件重命名为 .crash

2. 在报告顶部添加事件标识符行。这看起来像一个 GUID，因此您可以放置​​任何独特的内容或在线生成一个，例如

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

3. 添加 iOS 和崩溃报告版本行（就在异常类型上方），例如

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

   报告版本：104

回答by Kerni

1. <redacted>is an iOS optimization for system symbols only.
2. Uploading your app dSYM doesn't change a thing, since that only contains the app symbols, not the iOS system symbols of the required cpu architecture.
3. To symbolicate those locally you need to have the exact system symbols or the iOS version and architecture that created the crash.
4. Using atosto symbolicate a system symbol with your app binary/dSYM doesn't work (as mentioned above)
5. Getting a symbol by only passing in the address in the stack frame, never works, you also need to pass the load address of the corresponding binary (which can be found in the binary images section, the first address in the line of the binary)
6. In your atosexample you are trying an address which already shows proper symbols in the stack trace.
7. Dragging the crash report into the Xcode organizer should already symbolicate the report if you have the symbols available and you won't have to do the manual steps.
8. It looks like that Flurry doesn't have the iOS symbols on their server to resolve those symbols themselves.

1. <redacted>是仅针对系统符号的 iOS 优化。
2. 上传您的应用程序 dSYM 不会改变任何事情，因为它只包含应用程序符号，而不是所需 CPU 架构的 iOS 系统符号。
3. 要在本地对这些符号进行符号化，您需要拥有导致崩溃的确切系统符号或 iOS 版本和架构。
4. 使用atos您的应用程序二进制文件/dSYM 来符号化系统符号不起作用（如上所述）
5. 只通过栈帧中的地址来获取符号，永远行不通，还需要传递对应二进制的加载地址（可以在二进制图像部分找到，二进制行中的第一个地址）
6. 在您的atos示例中，您正在尝试一个地址，该地址已经在堆栈跟踪中显示了正确的符号。
7. 如果您有可用的符号并且不必执行手动步骤，则将崩溃报告拖到 Xcode 管理器中应该已经对报告进行了符号化。
8. 看起来 Flurry 在他们的服务器上没有 iOS 符号来自己解析这些符号。

So an example for 0x3a99ed7bof the libdispatch.dyliblibrary would be:

因此，对于一个例子0x3a99ed7b中的libdispatch.dylib图书馆是：

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

The root path for the iOS symbols on your Mac is: ~/Library/Developer/Xcode/iOS DeviceSupport/` with a subdirectory for each iOS version.

Mac 上 iOS 符号的根路径是：~/Library/Developer/Xcode/iOS DeviceSupport/`，每个 iOS 版本都有一个子目录。

So the simple solution: drag the crash report into the Device Logsentry in the Xcode organizer and hope you have everything required. If that doesn't remove at least some of the <redacted>strings, you are missing the iOS symbols and the manual steps won't work either.

所以简单的解决方案：将崩溃报告拖到Device LogsXcode 管理器中的条目中，并希望您拥有所需的一切。如果这至少没有删除一些<redacted>字符串，则您缺少 iOS 符号，手动步骤也将不起作用。

回答by skinsfan00atg

this worked for my flurry logs http://ipartymobile.com/how-to-find-your-bug-from-ios-crash-logs/didn't have to add anything to crash report, just took memory addresses and plugged in to this format “xcrun atos -arch armv7 -o MyApp 0x0000000"

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