问题
The problem is that when symbolicating the stacktrace addresses reported by PLCrashReporter doesn't return the actual system frameworks/libraries symbolicated line. My application line is though showing the correct offending line symbolicated.
Some configuration. I have on my OSX 10.9.5 installed the Xcode 5.1.1 and Xcode 6.0.1.
When working with the Xcode 5.1.1 and examine the device log I can see the crashes although no symbolication can take place in the crash report.
Using Xcode 6.0.1 crashing my app and examine the device log I can see the report symbolicated properly.
Atos in any case does not return the correct Apple system frameworks/libraries symbolicated line. It just return garbages, classes that has nothing to do with the corresponding framework/library. See below for examples.
In detail what I do to symbolicate my crash stacktrace reported to me using the PLCrashReporter and comparing to the device log symbolicated report.
Here is the stacktrace reported using the PLCrashReporter unsymbolicated:
0 libsystem_platform.dylib 0x000000019726ce5c 0x197268000 + 20060
1 libsystem_c.dylib 0x00000001971253e0 0x197124000 + 5088
2 MyNewPlugin 0x000000010003ac70 0x10002c000 + 60528
3 UIKit 0x000000018d5f90b0 0x18d5b0000 + 299184
4 UIKit 0x000000018d5f9044 0x18d5b0000 + 299076
5 UIKit 0x000000018d5e2520 0x18d5b0000 + 206112
6 UIKit 0x000000018d5f8a44 0x18d5b0000 + 297540
7 UIKit 0x000000018d5f86d8 0x18d5b0000 + 296664
8 UIKit 0x000000018d5f3370 0x18d5b0000 + 275312
9 UIKit 0x000000018d5c4b50 0x18d5b0000 + 84816
10 UIKit 0x000000018d5c2c40 0x18d5b0000 + 76864
11 CoreFoundation 0x000000018a5bb7f4 0x18a4f0000 + 833524
12 CoreFoundation 0x000000018a5bab50 0x18a4f0000 + 830288
13 CoreFoundation 0x000000018a5b8de8 0x18a4f0000 + 822760
14 CoreFoundation 0x000000018a4f9dd0 0x18a4f0000 + 40400
15 GraphicsServices 0x00000001901e1c0c 0x1901d4000 + 56332
16 UIKit 0x000000018d62afc4 0x18d5b0000 + 503748
17 MyNewPlugin 0x0000000100041944 0x10002c000 + 88388
18 libdyld.dylib 0x00000001970f7aa0 0x1970f4000 + 15008
Here is the stacktrace above from PLCrashReported symbolicated using "xcrun atos":
0 libsystem_platform.dylib _mh_execute_header (in MyNewPlugin) + 20060
1 libsystem_c.dylib _mh_execute_header (in MyNewPlugin) + 5088
2 MyNewPlugin -[SLKViewController causeBadAddress:] (in MyNewPlugin) (SLKViewController.m:175) + 60528
3 UIKit __30-[RequestWorker logEvent:]_block_invoke (in MyNewPlugin) + 232
4 UIKit __30-[RequestWorker logEvent:]_block_invoke (in MyNewPlugin) + 124
5 UIKit +[SSNetworkInfo cellMACAddress] (in MyNewPlugin) (SSNetworkInfo.m:0)
6 UIKit __copy_helper_block_234 (in MyNewPlugin) + 100
7 UIKit -[RequestWorker logEventAsyncWithName:logLevel:andCompletionBlock:] (in MyNewPlugin) + 992
8 UIKit -[ErrorResponse setData:] (in MyNewPlugin) + 56
9 UIKit +[SSProcessInfo processStatus] (in MyNewPlugin) (SSProcessInfo.m:97)
10 UIKit +[JSONModel(Networking) postModel:toURLWithString:completion:] (in MyNewPlugin) (JSONModel+networking.m:107)
11 CoreFoundation __55+[SPLJSONKeyMapper mapperFromUnderscoreCaseToCamelCase]_block_invoke_2 (in MyNewPlugin) + 1132
12 CoreFoundation __destroy_helper_block_17 (in MyNewPlugin) + 44
13 CoreFoundation -[RequestWorker sendUnhandledRequestAsync:andResultBlock:] (in MyNewPlugin) + 240
14 CoreFoundation +[SSApplicationInfo clipboardContent] (in MyNewPlugin) (SSApplicationInfo.m:49)
15 GraphicsServices __47-[SLKViewController logExceptionSynchronously:]_block_invoke (in MyNewPlugin) (SLKViewController.m:92) + 56332
16 UIKit -[DeviceInfo appendInfo] (in MyNewPlugin) + 1192
17 MyNewPlugin main (in MyNewPlugin) (main.m:16) + 88388
18 libdyld.dylib _mh_execute_header (in MyNewPlugin) + 15008
Here is the stacktrace of the above same exact crash from the device log symbolicated:
0 libsystem_platform.dylib 0x000000019726ce5c _platform_memmove + 188
1 libsystem_c.dylib 0x00000001971253dc strcpy + 40
2 MyNewPlugin 0x000000010003ac6c -[SLKViewController causeBadAddress:] (SLKViewController.m:174)
3 UIKit 0x000000018d5f90ac -[UIApplication sendAction:to:from:forEvent:] + 96
4 UIKit 0x000000018d5f9040 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 20
5 UIKit 0x000000018d5e251c -[UIControl _sendActionsForEvents:withEvent:] + 372
6 UIKit 0x000000018d5f8a40 -[UIControl touchesEnded:withEvent:] + 580
7 UIKit 0x000000018d5f86d4 -[UIWindow _sendTouchesForEvent:] + 688
8 UIKit 0x000000018d5f336c -[UIWindow sendEvent:] + 1168
9 UIKit 0x000000018d5c4b4c -[UIApplication sendEvent:] + 252
10 UIKit 0x000000018d5c2c3c _UIApplicationHandleEventQueue + 8496
11 CoreFoundation 0x000000018a5bb7f0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 20
12 CoreFoundation 0x000000018a5bab4c __CFRunLoopDoSources0 + 252
13 CoreFoundation 0x000000018a5b8de4 __CFRunLoopRun + 628
14 CoreFoundation 0x000000018a4f9dcc CFRunLoopRunSpecific + 448
15 GraphicsServices 0x00000001901e1c08 GSEventRunModal + 164
16 UIKit 0x000000018d62afc0 UIApplicationMain + 1152
17 MyNewPlugin 0x0000000100041940 main (main.m:16)
18 libdyld.dylib 0x00000001970f7a9c start + 0
You can see the two symbolicated stacktraces, first from PLCrashReporter stacktrace and second from the Xcode device log. I would like in this point to say that I don't believe it's the addresses that has the problem but more something going on with atos. Is Xcode using the symbolicatecrash tool to symbolicate the Apple report?
The atos command: xcrun atos -arch arm64 -o MyNewPlugin.app.dSYM/Contents/Resources/DWARF/MyNewPlugin -l 0x197268000 0x000000019726ce5c will result to _mh_execute_header (in MyNewPlugin) + 20060 which is completely wrong and it should return something like the device log report _platform_memmove + 188.
Another atos example to prove the problem for line 3.
xcrun atos -arch arm64 -o MyNewPlugin.app.dSYM/Contents/Resources/DWARF/MyNewPlugin -l 0x18d5b0000 0x000000018d5f90b0,
should return, UIKit 0x000000018d5f90ac -[UIApplication sendAction:to:from:forEvent:] + 96,
instead returns, UIKit __30-[RequestWorker logEvent:]_block_invoke (in MyNewPlugin) + 232 which has nothing to do with UIKit, this is an internal class I use.
This is how I create the lines of the stacktrace using PLCrashReporter.
[NSString stringWithFormat:@"%-4ld%@ 0x0000000%" PRIx64 " 0x%" PRIx64 " + %" PRId64 "", (long)frameIndex, imageName, frameInfo.instructionPointer, baseAddress, pcOffset];
EDIT: Using symbolicatecrash in the terminal for the unsymbolicated apple crash report is symbolicating all system assemblies but not the application lines!!!
回答1:
The answer was so simple but sometimes you don't see it in front of you.
Instead of using the application's dSYM you use the framework of the iOS version that the device has when crashed. e.g. for the UIKit symbols of the iOS 8.1.1
xcrun atos -arch arm64 -o ~/Library/Developer/Xcode/iOS DeviceSupport/8.1.1 (12B436)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit -l 0x18d5b0000 0x000000018d5f90b0
回答2:
here ya go iOS crash reports: atos not working as expected for application lines tedious it is though, have to go by a single line at a time.
来源：https://stackoverflow.com/questions/26079056/atos-does-not-symbolicate-system-frameworks-libraries-properly