Atos没有正确地表示系统框架/库 [英] Atos does not symbolicate system frameworks/libraries properly

查看:146
本文介绍了Atos没有正确地表示系统框架/库的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

问题在于,当PLCrashReporter报告的堆栈跟踪地址符号化时,不会返回实际的系统框架/库符号行。我的应用程序行虽然显示了符号化的正确违规行。

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.

某些配置。我在我的OSX 10.9.5上安装了Xcode 5.1.1和Xcode 6.0.1。

Some configuration. I have on my OSX 10.9.5 installed the Xcode 5.1.1 and Xcode 6.0.1.

使用Xcode 5.1.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.

使用Xcode 6.0.1崩溃我的应用程序并检查设备日志我可以看到报告符号正确。

Using Xcode 6.0.1 crashing my app and examine the device log I can see the report symbolicated properly.

Atos在任何情况下都不会返回正确的Apple系统框架/库符号行。它只返回与相应框架/库无关的垃圾。请参阅下面的示例。

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.

详细说明我使用PLCrashReporter向我报告的崩溃堆栈跟踪,并与设备日志符号化报告进行比较。

In detail what I do to symbolicate my crash stacktrace reported to me using the PLCrashReporter and comparing to the device log symbolicated report.

以下是使用PLC未示出的PLCrashReporter报告的堆栈跟踪:

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

以上是PLCrashReported上面的堆栈跟踪,使用xcrun atos符号表示:

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

您可以看到两个符号化的堆栈跟踪,首先来自PLCrashReporter堆栈跟踪,第二个来自Xcode设备日志。我想在这一点上说,我不相信这是有问题的地址,但更多的事情与atos一起发生。
Xcode是否使用symbolicatecrash工具来表示Apple报告?

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?

atos命令: xcrun atos -arch arm64 -o MyNewPlugin。 app.dSYM / Contents / Resources / DWARF / MyNewPlugin -l 0x197268000 0x000000019726ce5c 将导致 _mh_execute_header(在MyNewPlugin中)+ 20060 这是完全错误的它应该返回类似设备日志报告的内容 _platform_memmove + 188

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.

另一个atos示例来证明行的问题3.
xcrun atos -arch arm64 -o MyNewPlugin.app.dSYM / Contents / Resources / DWARF / MyNewPlugin -l 0x18d5b0000 0x000000018d5f90b0
应返回, UIKit 0x000000018d5f90ac - [UIApplication sendAction:to:from:forEvent:] + 96
代替返回, UIKit __30- [RequestWorker logEvent :] _ block_invoke(在MyNewPlugin中)+ 232 与UIKit无关,这是我使用的内部类。

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.

这是怎么回事我创建了stacktra的行使用PLCrashReporter。

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];

编辑:
在终端中使用symbolicatecrash进行非符号化苹果崩溃报告象征着所有的系统组件而不是应用程序线!!!

Using symbolicatecrash in the terminal for the unsymbolicated apple crash report is symbolicating all system assemblies but not the application lines!!!

推荐答案

答案很简单,但有时你不喜欢不要在你面前看到它。

The answer was so simple but sometimes you don't see it in front of you.

你不需要使用应用程序的dSYM,而是使用设备在崩溃时拥有的iOS版本的框架。例如对于iOS 8.1.1的UIKit符号

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)/符号/系统/库/框架/ UIKit.framework / UIKit -l 0x18d5b0000 0x000000018d5f90b0

xcrun atos -arch arm64 -o ~/Library/Developer/Xcode/iOS DeviceSupport/8.1.1 (12B436)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit -l 0x18d5b0000 0x000000018d5f90b0

这篇关于Atos没有正确地表示系统框架/库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆