We received the stack trace below from Flurry. It was captured from a user's device, and we have no way of tracing it. It doesn't list lines from our code base ... how can we troubleshoot 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
First, you need to get the base address for each of the modules listed on the left side (your app, plus every system library), because of Address Space Layout Randomization (ASLR). Many in-app stack trace reporting tools like PLCrashReporter can store this information in their report.
Next, you need to get the debug symbols for each module. For your app, when you build, it should produce a .dSym file, which contains the information that allows you to get the method and line numbers from the address. You need to make sure to get the exact .dSym that corresponds to the build that produced the crash, because each build is different.
For system libraries, the debug symbols are downloaded by Xcode the first time you connect a device to Xcode using a particular build of the OS. They are stored in /Users/<yourusername>/Library/Developer/Xcode/iOS DeviceSupport/. Note that sometimes versions of the OS will have multiple builds (betas, or different build for different devices); you need to get the OS build that the crash happened on, which means your stack trace will also need to store that information. It also needs to be an OS build that your Xcode has seen or else it won't have downloaded the information. For system modules, you will only get the function name and not the line number (which wouldn't be useful anyway since they are not open source).
Then, you can use the tool atos, give it an address, a load address (the base address of the module at issue), the architecture (for an app that includes code for multiple architectures), and it will output the symbol information for that address.
Related
I'm deploying a build to testers via TestFlight and the app is crashing. I cannot reproduce the crash on my end so I am trying to rely on the crash logs listed in Xcode Organizer.
Unfortunately the crashes here contain some information, but nothing that allows me to identify the line of code that is causing the crash. Usually when I click on a crash in the Organizer window, it automatically shows me the line in Xcode that caused the crash.
Here's the raw crash log, which also does not contain a line number, only the file and method in which the crash occured.
Thread 0 name:
Thread 0 Crashed:
0 libswiftCore.dylib 0x0000000103154b8c 0x102f64000 + 2034572
1 libswiftCore.dylib 0x0000000103154b8c 0x102f64000 + 2034572
2 libswiftCore.dylib 0x000000010316017c 0x102f64000 + 2081148
3 libswiftCore.dylib 0x0000000103105cfc 0x102f64000 + 1711356
4 libswiftCore.dylib 0x0000000103160984 0x102f64000 + 2083204
5 libswiftCore.dylib 0x00000001030ad2f8 0x102f64000 + 1348344
6 AppName 0x0000000102c92748 specialized TableViewController.sendSmsMessage(sender:) + 8816 (TableViewController.swift:0)
(TableViewController.swift:0)
7 AppName 0x0000000102c8c448 #objc TableViewController.CorF(sender:) + 44
8 UIKitCore 0x00000001ea7a6314 -[UIApplication sendAction:to:from:forEvent:] + 96 (UIApplication.m:4786)
9 UIKitCore 0x00000001ea233d54 -[UIControl sendAction:to:forEvent:] + 80 (UIControl.m:624)
10 UIKitCore 0x00000001ea234074 -[UIControl _sendActionsForEvents:withEvent:] + 440 (UIControl.m:707)
11 UIKitCore 0x00000001ea233074 -[UIControl touchesEnded:withEvent:] + 568 (UIControl.m:461)
12 UIKitCore 0x00000001ea7dfa6c -[UIWindow _sendTouchesForEvent:] + 2472 (UIWindow.m:2204)
13 UIKitCore 0x00000001ea7e0cd0 -[UIWindow sendEvent:] + 3156 (UIWindow.m:2453)
14 UIKitCore 0x00000001ea7bffcc -[UIApplication sendEvent:] + 340 (UIApplication.m:10819)
15 UIKitCore 0x00000001ea88ee38 __dispatchPreprocessedEventFromEventQueue + 1620 (UIEventDispatcher.m:1678)
16 UIKitCore 0x00000001ea891830 __handleEventQueueInternal + 4740 (UIEventDispatcher.m:1937)
17 UIKitCore 0x00000001ea88a320 __handleHIDEventFetcherDrain + 152 (UIEventDispatcher.m:1905)
18 CoreFoundation 0x00000001bd44a0e0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 (CFRunLoop.c:1980)
19 CoreFoundation 0x00000001bd44a060 __CFRunLoopDoSource0 + 88 (CFRunLoop.c:2015)
20 CoreFoundation 0x00000001bd449944 __CFRunLoopDoSources0 + 176 (CFRunLoop.c:2051)
21 CoreFoundation 0x00000001bd444810 __CFRunLoopRun + 1040 (CFRunLoop.c:2922)
22 CoreFoundation 0x00000001bd4440e0 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3247)
23 GraphicsServices 0x00000001bf6bd584 GSEventRunModal + 100 (GSEvent.c:2245)
24 UIKitCore 0x00000001ea7a4c00 UIApplicationMain + 212 (UIApplication.m:4347)
25 AppName 0x0000000102c7d0f0 main + 60 (SMS.swift:12)
26 libdyld.dylib 0x00000001bcf02bb4 start + 4
Any idea on how I can determine the line that is causing the crash?
EDIT: I was able to get the user to send me a crash report stored on their device as suggested by #Václav, but it doesn't seem to contain much helpful information either:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x0000000104e774ec 0x104c8c000 + 2012396
1 libswiftCore.dylib 0x0000000104e774ec 0x104c8c000 + 2012396
2 libswiftCore.dylib 0x0000000104e828cc 0x104c8c000 + 2058444
3 libswiftCore.dylib 0x0000000104e28fd4 0x104c8c000 + 1691604
4 libswiftCore.dylib 0x0000000104e830cc 0x104c8c000 + 2060492
5 libswiftCore.dylib 0x0000000104dd142c 0x104c8c000 + 1332268
6 AppName 0x00000001047fa948 0x1047e0000 + 108872
7 AppName 0x00000001047f4784 0x1047e0000 + 83844
8 UIKitCore 0x00000001e6fe6314 0x1e66fc000 + 9347860
9 UIKitCore 0x00000001e6a73d54 0x1e66fc000 + 3636564
10 UIKitCore 0x00000001e6a74074 0x1e66fc000 + 3637364
11 UIKitCore 0x00000001e6a73074 0x1e66fc000 + 3633268
12 UIKitCore 0x00000001e6bfaaf0 0x1e66fc000 + 5237488
13 UIKitCore 0x00000001e6bf57ec 0x1e66fc000 + 5216236
14 UIKitCore 0x00000001e6bf52cc 0x1e66fc000 + 5214924
15 UIKitCore 0x00000001e6bf509c 0x1e66fc000 + 5214364
16 UIKitCore 0x00000001e7020cb4 0x1e66fc000 + 9587892
17 UIKitCore 0x00000001e6ffffcc 0x1e66fc000 + 9453516
18 UIKitCore 0x00000001e70cee38 0x1e66fc000 + 10300984
19 UIKitCore 0x00000001e70d1830 0x1e66fc000 + 10311728
20 UIKitCore 0x00000001e70ca320 0x1e66fc000 + 10281760
21 CoreFoundation 0x00000001b9c8a0e0 0x1b9bdd000 + 708832
22 CoreFoundation 0x00000001b9c8a060 0x1b9bdd000 + 708704
23 CoreFoundation 0x00000001b9c89944 0x1b9bdd000 + 706884
24 CoreFoundation 0x00000001b9c84810 0x1b9bdd000 + 686096
25 CoreFoundation 0x00000001b9c840e0 0x1b9bdd000 + 684256
26 GraphicsServices 0x00000001bbefd584 0x1bbef2000 + 46468
27 UIKitCore 0x00000001e6fe4c00 0x1e66fc000 + 9341952
28 AppName 0x00000001047e5860 0x1047e0000 + 22624
29 libdyld.dylib 0x00000001b9742bb4 0x1b9742000 + 2996
There are a few different elements to this question, so let me try to break it down.
Why do I see line 0?
The Swift compiler does a fair amount of code generation before actually producing a final compiled binary. In this situation, line 0 is the compiler's way of telling you that it generated code while compiling TableViewController.swift, but that code doesn't correspond to a specific line in the original source.
Because you've got a specialized function here, I'm much more inclined to believe this is compiler-generated code. This usually means the compiler is working with generic types.
I'm disappointed that Apple communicates this event in this way, but there's not much we can do. My understanding is that DWARF can describe this kind of thing. But, either Apple doesn't use this facility, it isn't written to crash reports, or most likely both.
You can verify this behavior by using atos or dwarfdump to symbolication the address 0x0000000102c92748. My bet is it will output exactly the same thing - line 0. In the past I've used dwarfdump to poke around here to see if there was more info encoded in the dSYM, but I didn't find anything. It was a few years ago though, so things might have changed.
Might a 3rd party crash reporter help?
They all use the dSYM to symbolicate, so they cannot have more information than is contained in that file. It could be worth a shot, regardless, but I doubt you'll get anywhere on the line 0 thing.
However, they probably will be able to symbolicate the frames from libswiftCore.dylib, which could be very helpful.
Why did this crash happen?
This is the million dollar question.
I'd like to see the actual crash details. My guess is it is an illegal instruction, because you've crashed inside a swift runtime library. What's likely happening is the runtime has tripped on some kind of illegal state. Unwrapping a nil Optional could definitely be it. Could also be an out of bounds Range operation. I think that out-of-bounds array indexes might also fail in this way, but off the top of my head, I'm not sure.
What I would do is just take a close look at what's going on in TableViewController.sendSmsMessage(sender:). Pay close attention to the things listed above, particularly if it is interacting with any generic standard library functions.
I would also make an attempt to symbolicate those libswiftCore.dylib frames. Again, you can use atos for this, just by pointing it at the library itself and using the load address. I'm unsure where Xcode keeps the Swift libraries internally, so you might just use the copy of the lib that was bundled with your app.
Good luck!
Goal:
I want to symbolicate the "output" of [NSThread callStackSymbols].
Side Notes:
I know how to do that with crash logs. However, I need to investigate some problems where I would like to look at the call stack. Unfortunately these days the framework's addresses are all <redacted>. Causing a crash at the right points (or at the end - see end of my question) is not really acceptable, but if I cannot find another solution, it will be the way to go.
I have to run my tests on a device, so I cannot use the Simulator.
Current approach:
When I call this:
NSLog(#"call stack:\n%#", [NSThread callStackSymbols]);
I get this output:
2015-12-08 15:04:03.888 Conversion[76776:4410388] call stack:
(
0 Conversion 0x000694b5 -[ViewController viewDidLoad] + 128
1 UIKit 0x27259f55 <redacted> + 1028
...
9 UIKit 0x274f67a7 <redacted> + 134
10 FrontBoardServices 0x2b358ca5 <redacted> + 232
11 FrontBoardServices 0x2b358f91 <redacted> + 44
12 CoreFoundation 0x230e87c7 <redacted> + 14
...
16 CoreFoundation 0x23038ecd CFRunLoopRunInMode + 108
17 UIKit 0x272c7607 <redacted> + 526
18 UIKit 0x272c22dd UIApplicationMain + 144
19 Conversion 0x000767b5 main + 108
20 libdyld.dylib 0x34f34873 <redacted> + 2
)
("Conversion" in this output is the app.)
Now I can use this command to "symbolicate" addresses:
xcrun atos -o /path/to/Conversion.app -arch arm64 -l 0x0???
Run like that (of course with a proper value for -l), I can enter addresses like 0x000694b5 and it will spit out something like -[ViewController viewDidLoad] + 128. Of course the problem is the start address (the -l option's value).
When I have a crash log, I can get those. However, I would like to get away without a crash.
Questions:
Q1: Can I determine the start address at runtime and maybe include it in the log output so I can feed it to the atos -l option?
EDIT: It looks like this is possible like this: (thanks to NSProgrammer for answer https://stackoverflow.com/a/12464678/1396265)
#import <mach-o/dyld.h>
...
intptr_t slide = _dyld_get_image_vmaddr_slide(0);
const struct mach_header * load_addr = _dyld_get_image_header(0);
NSLog(#"slide %lx load addr %lx", (long)slide, (long)load_addr);
/EDIT
(As I am interested in the framework's method calls, I certainly need the start addresses of the frameworks. The app's start address changes frequently (randomization), I do not yet know, whether or not the framework's start addresses are randomized.)
Q2: Are there other approaches to investigating the methods in the call stack? (breakpoints are also rather clumsy in my scenario.)
EDIT:
Q3: How can I symbolicate the addresses of the frameworks? For instance where can I find the dSYM (or whatever it takes) for UIKit?
(For instance I have something at: ~/Library/Developer/Xcode/iOS\ DeviceSupport/9.1\ \(13B143\)/Symbols/System/Library/Frameworks/UIKit.framework/. I'll look into more details here.)
/EDIT
Maybe a solution:
One way might be, to save the log output to a file, and at the end of the tests cause a crash in the app. That way the crash log would reveal the start addresses and with the call stack information from the logs I should be able to symbolicate the callStackSymbols output. I will try that next.
Adding log snippets to the crash log worked well so far, so I'll add this as an answer for now. (Better answers are definitely welcome :-) )
Preparations:
Add callStackSymbols logging at the relevant places in the source code:
NSLog(#"call stack:\n%#", [NSThread callStackSymbols]);
Make the app crash (for instance when a certain screen is opened):
strcpy(0, "000");
Redirect logging output to a file:
FILE *logfile = freopen([pathForLog cStringUsingEncoding:NSASCIIStringEncoding], "a+", stderr);
Execution:
In Xcode run the app once, so it gets installed on the device, and then stop it.
Then start the app directly on the device, so Xcode won't catch the crash.
Use the app so that the call stack is logged (can be many times).
Eventually make the app crash (in my case, open a certain screen which calls the bad strcpy).
Getting the files:
In Xcode open "Window -> Devices", select the device, select the app and download the app container, so the log file can be extracted.
In the same screen open the device logs and export the crash log.
In Xcode open "Window -> Projects", select the project and make it show the derived data folder in the Finder (little arrow button to the right of the derived data path). In the derived data folder navigate to "Build/Products/Debug-iphoneos/" and copy MyApp.app and MyApp.app.dSYM.
Adjust the crash log:
For me it worked to add extra thread sections right before "Binary Images:". So find the location of "Binary Images:". Insert a line "Thread 9999:". Copy&paste the call stack dumps and remove the leading whitespace columns so that it looks like this:
2015-12-09 15:28:58.971 MyApp[21376:3050653] call tree (
Thread 9999:
0 MyApp 0x00000001001d95f8 -[MyClass myMethod:] + 100
1 UIKit 0x000000018a5fc2ac <redacted> + 172
2 UIKit 0x000000018a5d5ca4 <redacted> + 88
3 UIKit 0x000000018a5d5b8c <redacted> + 460
4 UIKit 0x000000018a5d5cc0 <redacted> + 116
5 UIKit 0x000000018a5d5b8c <redacted> + 460
6 UIKit 0x000000018a5d5cc0 <redacted> + 116
7 UIKit 0x000000018a5d5b8c <redacted> + 460
8 UIKit 0x000000018a8e85ac <redacted> + 460
9 UIKit 0x000000018a5d4abc <redacted> + 96
10 UIKit 0x000000018a935b7c <redacted> + 344
11 UIKit 0x000000018a9306f8 <redacted> + 124
12 UIKit 0x000000018aa584d8 <redacted> + 44
13 UIKit 0x000000018a933d9c <redacted> + 188
14 UIKit 0x000000018a70b668 <redacted> + 116
15 UIKit 0x000000018a70b454 <redacted> + 252
16 UIKit 0x000000018a70af38 <redacted> + 1404
17 UIKit 0x000000018a70a9a8 <redacted> + 124
18 UIKit 0x000000018a616d3c <redacted> + 312
19 UIKit 0x000000018a616bc4 <redacted> + 108
20 QuartzCore 0x0000000189dddc2c <redacted> + 284
21 libdispatch.dylib 0x000000019a3a96a8 <redacted> + 16
22 libdispatch.dylib 0x000000019a3aedb0 _dispatch_main_queue_callback_4CF + 1844
23 CoreFoundation 0x00000001850001f8 <redacted> + 12
24 CoreFoundation 0x0000000184ffe060 <redacted> + 1628
25 CoreFoundation 0x0000000184f2cca0 CFRunLoopRunSpecific + 384
26 GraphicsServices 0x000000018ff94088 GSEventRunModal + 180
27 UIKit 0x000000018a644ffc UIApplicationMain + 204
28 MyApp 0x0000000100093918 main + 124
29 libdyld.dylib 0x000000019a3da8b8 <redacted> + 4
Binary Images:
...
The "Thread 9999:" line makes the symbolicatecrash script want to symbolicate the next lines. I chose 9999 so I know, that these were my added sections.
Run symbolication:
Find the symbolicatecrash script:
$ find /Applications/Xcode.app -name symbolicatecrash -type f
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
$
The symbolication command goes almost like this:
$ symbolicatecrash myapp.crash MyApp.app.dSYM > myapp-sym.crash
You need to set DEVELOPER_DIR and prepend the path to the script, so eventually it looks like this:
$ DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer' /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash myapp.crash MyApp.app.dSYM > myapp-sym.crash
Or wrapped for better viewing pleasure:
$ DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer' ...
/Applications/Xcode.app/Contents/SharedFrameworks/ ...
DTDeviceKitBase.framework/Versions/A/Resources/ ...
symbolicatecrash myapp.crash MyApp.app.dSYM > myapp-sym.crash
The result:
The symbolicated snippets now look like this:
2015-12-09 15:28:58.971 MyApp[21376:3050653] call tree (
Thread 9999:
0 MyApp 0x00000001001d95f8 -[MyClass myMethod:] (MyFile.m:15)
1 UIKit 0x000000018a5fc2ac -[UIScrollView _willMoveToWindow:] + 172
2 UIKit 0x000000018a5d5ca4 __85-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]_block_invoke + 88
3 UIKit 0x000000018a5d5b8c -[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] + 460
4 UIKit 0x000000018a5d5cc0 __85-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]_block_invoke + 116
5 UIKit 0x000000018a5d5b8c -[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] + 460
6 UIKit 0x000000018a5d5cc0 __85-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]_block_invoke + 116
7 UIKit 0x000000018a5d5b8c -[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] + 460
8 UIKit 0x000000018a8e85ac __UIViewWillBeRemovedFromSuperview + 460
9 UIKit 0x000000018a5d4abc -[UIView(Hierarchy) removeFromSuperview] + 96
10 UIKit 0x000000018a935b7c __71-[UIPresentationController _initViewHierarchyForPresentationSuperview:]_block_invoke596 + 344
11 UIKit 0x000000018a9306f8 -[UIPresentationController transitionDidFinish:] + 124
12 UIKit 0x000000018aa584d8 -[_UICurrentContextPresentationController transitionDidFinish:] + 44
13 UIKit 0x000000018a933d9c __56-[UIPresentationController runTransitionForCurrentState]_block_invoke_2 + 188
14 UIKit 0x000000018a70b668 -[_UIViewControllerTransitionContext completeTransition:] + 116
15 UIKit 0x000000018a70b454 -[UITransitionView notifyDidCompleteTransition:] + 252
16 UIKit 0x000000018a70af38 -[UITransitionView _didCompleteTransition:] + 1404
17 UIKit 0x000000018a70a9a8 -[UITransitionView _transitionDidStop:finished:] + 124
18 UIKit 0x000000018a616d3c -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
19 UIKit 0x000000018a616bc4 -[UIViewAnimationState animationDidStop:finished:] + 108
20 QuartzCore 0x0000000189dddc2c CA::Layer::run_animation_callbacks(void*) + 284
21 libdispatch.dylib 0x000000019a3a96a8 _dispatch_client_callout + 16
22 libdispatch.dylib 0x000000019a3aedb0 _dispatch_main_queue_callback_4CF + 1844
23 CoreFoundation 0x00000001850001f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
24 CoreFoundation 0x0000000184ffe060 __CFRunLoopRun + 1628
25 CoreFoundation 0x0000000184f2cca0 CFRunLoopRunSpecific + 384
26 GraphicsServices 0x000000018ff94088 GSEventRunModal + 180
27 UIKit 0x000000018a644ffc UIApplicationMain + 204
28 MyApp 0x0000000100093918 main (main.m:16)
29 libdyld.dylib 0x000000019a3da8b8 <redacted> + 4
Binary Images:
...
Unless I find an easier approach, this will be the way to go for now for me. It may be useful to create a script which pulls the call stacks from the log file, removes the leading whitespace and inserts those into the crash log.
SYMBOLICATECRASH
Apple ships a script with XCode that expedites the symbolication process of a crash report in its entirety. If you have a dSYM, your app binary and a crash report, this is probably the easiest method of symbolication. You don’t have to worry about any of the addresses – this script will parse the whole crash dump file and use ATOS to resolve all of the addresses into symbols for you.
Locate the “symbolicatecrash” on your system:
cd /Applications/Xcode.app
find . -name symbolicatecrash
Export the DEVELOPER_DIR environment variable, if it doesn’t exist
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
Copy your .app binary, the crash report, and the .dSYM file to a temporary folder (ex. ~/tmp).
Run the script like our example below:
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v ApteligentExampleApp.crash ApteligentExampleApp.app.dSYM/
If all goes well, the script should symbolicate your entire crash file and output the result to your terminal window. This script doesn’t do anything you couldn’t do manually with ATOS or another tool, but it will get you what you need much quicker.
Source
Below is a portion of the crash log for my application which occurred in iPhone 6 Plus (arm64):
0 libobjc.A.dylib 0x35b4ef66 objc_msgSend + 6
1 UIKit 0x2a905dd1 -[UIScrollView setContentOffset:] + 626
2 UIKit 0x2aa871b9 -[UIAnimator(Static) _advanceAnimationsOfType:withTimestamp:] + 270
3 UIKit 0x2aa870a5 -[UIAnimator(Static) _LCDHeartbeatCallback:] + 50
4 QuartzCore 0x2a34cb67 _ZN2CA7Display15DisplayLinkItem8dispatchEv + 96
5 QuartzCore 0x2a34c9cf _ZN2CA7Display11DisplayLink14dispatch_itemsEyyy + 364
6 IOMobileFramebuffer 0x2f0f9c03 IOMobileFramebufferVsyncNotifyFunc + 88
7 IOKit 0x28204d0d IODispatchCalloutFromCFMessage + 254
8 CoreFoundation 0x27240555 __CFMachPortPerform + 130
9 CoreFoundation 0x27250a4b __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
10 CoreFoundation 0x272509e7 __CFRunLoopDoSource1 + 344
11 CoreFoundation 0x2724f009 __CFRunLoopRun + 1606
12 CoreFoundation 0x2719a9a1 CFRunLoopRunSpecific + 474
13 CoreFoundation 0x2719a7b3 CFRunLoopRunInMode + 104
14 GraphicsServices 0x2eb421a9 GSEventRunModal + 134
15 UIKit 0x2a94b635 UIApplicationMain + 1438
16 MyOwnApp 0x00039c67 main (main.m:37)
17 libdyld.dylib 0x36110aaf start + 0
I have verified the UUID of the .app file and the .dsym file using the dwarfdump and verified that they both have the same UUID. The UUID mention in the crash report is mentioned for arm64.
Now when I execute the command:
atos -arch arm64 MyOwnApp.app/MyOwnApp 0x00039c67
The output of the command is the same hex address 0x00039c67. But when I change the arch from arm64 to armv7, then it specifies a method name.
Also if I see main.m, line 37 in the build output (I am coding in Appcelerator), then it just calls UIApplication function, which I think might be the entry point of the application. I am not into iOS native development.
Can someone please help me in this regard.
It's stack trace, so most recent calls are on top.
Please provide error message.
I'm trying to get backtrace symbol like Xcode listout as below
*** First throw call stack:
(
0 CoreFoundation 0x018865e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x016098b6 objc_exception_throw + 44
2 CoreFoundation 0x01923903 -[NSObject(NSObject) doesNotRecognizeSelector:] + 275
3 CoreFoundation 0x0187690b ___forwarding___ + 1019
4 CoreFoundation 0x018764ee _CF_forwarding_prep_0 + 14
5 Foundation 0x0124036c __NSFireDelayedPerform + 372
6 CoreFoundation 0x01844c46 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
7 CoreFoundation 0x0184462d __CFRunLoopDoTimer + 1181
8 CoreFoundation 0x0182c698 __CFRunLoopRun + 1816
9 CoreFoundation 0x0182bb33 CFRunLoopRunSpecific + 467
10 CoreFoundation 0x0182b94b CFRunLoopRunInMode + 123
11 GraphicsServices 0x02c249d7 GSEventRunModal + 192
12 GraphicsServices 0x02c247fe GSEventRun + 104
13 UIKit 0x0037c94b UIApplicationMain + 1225
14 CrashHandler 0x000088ad main + 141
15 libdyld.dylib 0x06244725 start + 0
16 ??? 0x00000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
I'm trying to extract symbol from NSException as below code. and less information only available.
-(void)handleException:(NSException*)exception
{
[exception callStackSymbols]//I've written this into file.
}
I've got output as below
*** First throw call stack: (
0 CoreFoundation 0x326bd2bb <redacted> + 186
1 libobjc.A.dylib 0x3a33b97f objc_exception_throw + 30
2 CoreFoundation 0x326c0e07 <redacted> + 170
3 CoreFoundation 0x326bf531 <redacted> + 392
4 CoreFoundation 0x32616f68 _CF_forwarding_prep_0 + 24
5 Foundation 0x32fcb277 <redacted> + 450
6 CoreFoundation 0x326925df <redacted> + 14
7 CoreFoundation 0x32692291 <redacted> + 272
8 CoreFoundation 0x32690f01 <redacted> + 1232
9 CoreFoundation 0x32603ebd CFRunLoopRunSpecific + 356
10 CoreFoundation 0x32603d49 CFRunLoopRunInMode + 104
11 GraphicsServices 0x361b62eb GSEventRunModal + 74
12 UIKit 0x34519301 UIApplicationMain + 1120
13 CrashHandler 0x0007f421 main + 116
14 libdyld.dylib 0x3a772b20 <redacted> + 0
)
How to decode <redacted> symbol?
Reference and Understanding:
I've refer SO post1, SO post2 but It need dSYM file and we have to manually decode as like testflight.. Without dSYM file, how to do this?
Symbolication is the process of translation a memory address to a symbol that contains all or some of the following elements:
class name
method name
file name
line number
When symbolicating on the device with the app symbols being part of the app binary, only class name and method name can be retrieved. It is not possible to get file name and line number this way.
When symbolicating using the app dSYM, it is possible to get all data, as long all information is available when building the app. E.g. when using third party static libraries, file name and line number might be missing for those calls.
<redacted> symbols can only show up for system calls when symbolicating system framework addresses on the device. The reason the class name and/or method name doesn't show up is an iOS memory optimization. Explanation for this can be found here: https://devforums.apple.com/thread/171264
To symbolicate these addresses, you need to have the iOS symbols of the iOS version and CPU architecture that was used to create the stack trace on the computer that is symbolicating the report.
It is possible to get these symbols as part of Xcode or by connecting a device of the specific iOS version and CPU architecture to Xcode, which will then fetch the symbols. Note that e.g. for iOS bugfix versions that do not come with an updated SDK, the only way to get the symbols is using a device.
Symbolication on a computer can be done using Xcode organizer or manually using the symbolciatecrash.pl script which is part of Xcode manually in the terminal.
For symbolication to work with Xcode or the script, you need a full crash report which contains lots more information than your posted stack trace.
To use atos to manually symbolicate the frame addresses of your report, you'll also need the load address for each binary that a frame references, e.g. from Foundation, CoreFoundation, UIKit. The shown stack trace doesn't provide this information. There are multiple posts here on StackOverflow how to use atos manually.
There is no way to symbolicate the trace without a dSYMbolication file.
You could try to build your code with the option not to strip debug symbols but I'm not sure.
Also implementing a crash handler is a very delicate task that I would leave to pro's ;)
Yet you can give it a try and probably learn new things.
I'm receiving crash reports from an app but Xcode is not able to symbolicate the symbols that are specific to my app:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x32c43a1c __pthread_kill + 8
1 libsystem_c.dylib 0x33a0a3b4 pthread_kill + 52
2 libsystem_c.dylib 0x33a02bf8 abort + 72
3 libsystem_c.dylib 0x33a306d4 __assert_rtn + 140
4 MyApplication 0x0000dd54 0x9000 + 19796
5 MyApplication 0x0000dbda 0x9000 + 19418
6 MyApplication 0x000103f6 0x9000 + 29686
7 MyApplication 0x0001035e 0x9000 + 29534
8 MyApplication 0x0000f3cc 0x9000 + 25548
9 MyApplication 0x00025d1e 0x9000 + 118046
10 CoreFoundation 0x35847efc -[NSObject(NSObject) performSelector:withObject:] + 16
11 Foundation 0x36eec7a2 __NSThreadPerformPerform + 262
12 CoreFoundation 0x358b1a72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
13 CoreFoundation 0x358b3758 __CFRunLoopDoSources0 + 376
14 CoreFoundation 0x358b44e4 __CFRunLoopRun + 224
15 CoreFoundation 0x35844ebc CFRunLoopRunSpecific + 224
16 CoreFoundation 0x35844dc4 CFRunLoopRunInMode + 52
17 GraphicsServices 0x3446b418 GSEventRunModal + 108
18 GraphicsServices 0x3446b4c4 GSEventRun + 56
19 UIKit 0x344a2d62 -[UIApplication _run] + 398
20 UIKit 0x344a0800 UIApplicationMain + 664
21 MyApplication 0x0000b174 main (main.m:14)
22 MyApplication 0x0000b124 0x9000 + 8484
Except for the line in main.m. I know I have the dSYM file for it still in Xcode's archive. I've tried using the command line to reference those debug symbols directly, but I get the same result every time. I've tried using atos to lookup the symbol directly and it wasn't able to find it. I verified that it was the right dSYM by comparing the UUID.
It finds main.m every time, so it seems like its half working, but just not able to find anything else.
I am using a static library in this app--is it possible that the crash is occurring in the static library? Would that debug information be in a separate set of debug symbols? It says that the responsible library is my application...would it say the name of the static library if it was in fact responsible for the crash?
Thanks!
Static libraries are linked into your app executable, so after linking you won't be able to identify the original source of that code. Hence it will always name your app as the source binary.
It is likely that those frames are not getting symbolicated, because of the static library you included. This happens if the static library doesn't have the symbols in it, but stripped of. Happens quite often for static library release builds, where the default setting is the same as for apps, to strip of the symbols. (For apps this is the correct thing to do!)
In that case the symbols wouldn't be copied into the dSYM, because it can't find them in the static library.