Debug stack trace?
We got the stack trace below from Flurry. It was captured from a user device and we cannot track it. It doesn't list lines from our codebase ... how can we eliminate the stack trace and isolate the problem?
Full stack trace:
0 libGPUSupportMercury.dylib 0x34d068f6 <redacted> + 9
1 IMGSGX535GLDriver 0x2f04050f <redacted> + 122
2 GLEngine 0x32515a01 <redacted> + 172
3 GLEngine 0x3251590f _gliPresentViewES + 134
4 OpenGLES 0x325200cd <redacted> + 64
5 SpriteKit 0x32990191 -[SKView _renderContent] + 1216
6 libdispatch.dylib 0x3af1381f <redacted> + 22
7 libdispatch.dylib 0x3af25dd7 <redacted> + 26
8 SpriteKit 0x3298fca3 -[SKView renderContent] + 82
9 SpriteKit 0x3298d633 <redacted> + 130
10 SpriteKit 0x329b00eb -[SKDisplayLink _callbackForNextFrame:] + 254
11 QuartzCore 0x32766df3 <redacted> + 98
12 QuartzCore 0x32766b9d <redacted> + 344
13 IOMobileFramebuffer 0x354df75d <redacted> + 104
14 IOKit 0x30f69451 _IODispatchCalloutFromCFMessage + 248
15 CoreFoundation 0x3023eef9 <redacted> + 136
16 CoreFoundation 0x30249ab7 <redacted> + 34
17 CoreFoundation 0x30249a53 <redacted> + 346
18 CoreFoundation 0x30248227 <redacted> + 1398
19 CoreFoundation 0x301b2f4f _CFRunLoopRunSpecific + 522
20 CoreFoundation 0x301b2d33 _CFRunLoopRunInMode + 106
21 GraphicsServices 0x350b7663 _GSEventRunModal + 138
22 UIKit 0x32afe16d _UIApplicationMain + 1136
23 <OurClassName> 0x000af494 __mh_execute_header + 345236
24 libdyld.dylib 0x3af38ab7 <redacted> + 2
source to share
First you need to get the base address for each of the modules listed on the left (your application as well as each system library) due to Address Space Layout Randomization (ASLR). Many in-app traffic reporting tools such as PLCrashReporter can store this information in their report.
Then you need to get the debug symbols for each module. For your application, when you build, it should create a .dSym file that contains information that allows you to get the method and line numbers from the address. You have to make sure you get the exact .dSym that matches the assembly that crashed because each assembly is different.
For system libraries, debug symbols are loaded by Xcode the first time you connect a device to Xcode using a specific OS build. They are stored in /Users/<yourusername>/Library/Developer/Xcode/iOS DeviceSupport/
. Please note that sometimes OS versions will have multiple builds (beta versions or different builds for different devices); you need to get the OS assembly that crashed, which means the stack trace must store this information as well. It must also be the OS build that your Xcode saw, otherwise it won't load information. For system modules, you only get the function name, not the line number (which would be useless since they are not open source).
Then you can use the tool atos
, give it an address, a load address (base address of a faulty module), an architecture (for an application that includes code for multiple architectures), and it will output the symbol information for that address.
source to share