Symbolicating an iOS 7 crash report using Flurry Crash Analytics

Question

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.

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 download gives me a file (without extension, so I renamed it to .crash) with this content:

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

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.

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!

Answer 1

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

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

Answer 2

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 atos to 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 atos example 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.

So an example for 0x3a99ed7b of the libdispatch.dylib library would be:

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.

So the simple solution: drag the crash report into the Device Logs entry 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.

Answer 3

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"