SIGSEGV SEGV_ACCERR崩溃报告 - 该怎么办? [英] SIGSEGV SEGV_ACCERR Crash Reports - What to do?

查看:7819
本文介绍了SIGSEGV SEGV_ACCERR崩溃报告 - 该怎么办?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚在AppStore上发布了一个应用程序,其中包含 Crittercism 崩溃报告,而且我收到了几个崩溃报告一个SIGSEGV错误。 Crittercism给了我一个StackTrace和一些方便的细节关于使用统计信息等,然而,我仍然被这些符号化的堆栈跟踪。我有一些关于这种事情的一般问题 -


  1. Stack Trace中的许多类和方法都不是甚至用在我的应用程序(据我所知),这导致我相信这些崩溃是由于来自苹果的私人API。看看这个问题底部附近的堆栈跟踪。 如果崩溃报告中的所有方法和类都没有在我的代码中直接实现,那么如何判断应用崩溃的原因?


  2. p> + 标志在崩溃线程中代表每行结尾处的数字?


  3. 大多数在计算器上Q / A的询问SIGSEGV崩溃说,他们是由内存泄漏或问题,的然而我怎么能有一个崩溃,因为引起的如果我在我的iOS项目中使用ARC,会出现内存问题?是不是ARC应该为我管理所有这些事情?


  4. 如果我无法复制错误/崩溃,该怎么办?


  5. 阅读 StackTrace?有一般的东西,这将是有益的理解发生了什么?




下面是堆栈跟踪主线程从Crittercism崩溃报告,这个问题涉及到:

 主题:未知名称(崩溃)
0的UIKit 0x37307a22 - [的UIView(CALayerDelegate)actionForLayer:forKey:] + 138
1 QuartzCore 0x38fdfff7 - [CALayer的actionForKey:] + 75
2 QuartzCore 0x38fdffa7 _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 59
3 QuartzCore 0x38fdfe93 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131
4 QuartzCore 0x38fdab87 _ZN2CA5Layer6setterEj12_CAValueTypePKv + 183
5 QuartzCore 0x39007057 - [CALayer的setBackgroundColor:] + 35
6 UIKit的0x3731ef51 - [UIView的(内部)_setBackgroundCGColor:withSystemColorName:] + 1021
7 APP NAME 0x000a301d 0x00086000 + 118813
8 libdispatch.dylib 0x3962511f _dispatch_call_block_and_release + 11
9 libdispatch.dylib 0x39628ecf _dispatch_queue_drain $ VARIANT $ MP + 143
10 libdispatch.dylib 0x39628dc1 _dispatch_queue_invoke $ VARIANT $ MP + 41
11 libdispatch.dylib 0x3962991d _dispatch_root_queue_drain + 185
12 libdispatch.dylib 0x39629ac1 _dispatch_worker_thread2 + 85
13 libsystem_c.dylib 0x3824da11 _pthread_wqthread + 361


解决方案

您需要将此崩溃报告作为符号。数字7是你感兴趣的行,但没有符号信息,所以崩溃报告不能被翻译成有用的东西。为了符号化,您需要在应用商店发布中使用的确切代码。如果有,您可以参考此答案:



http:/ /stackoverflow.com/a/13280585/1155387



至于其他方面:



1)不要这么快就承担内部的API错误。你的函数显然改变了视图的背景颜色,它在内部调用各种方法。它可能以某种方式通过了无效的值。不要那么幼稚,认为你写的代码是唯一执行的代码。



2)+符号表示该代码在二进制内部的偏移量目的。



3)您可以很容易地与ARC发生内存错误,因为ARC只处理 Objective-C 。任何CoreFoundation对象等都不会被管理。这不一定是这里发生的,但ARC并不意味着你必须停止一起思考记忆。



4)见上文



5)见上面


I've just released an app on the AppStore with Crittercism crash reporting and I've been getting quite a few crash reports pertaining to a SIGSEGV error. Crittercism gives me a StackTrace and a few handy details about usage statistics, etc. however, I'm still befuddled by these symbolized stack traces. I have a few questions in general about this kind of thing -

  1. Many of the classes and methods in the Stack Trace are not even used in my app (to my knowledge), which leads me to believe that these crashes are due to private APIs from Apple. Take a look at the Stack Trace near the bottom of this question. How can I tell what's crashing my app if all of the methods and classes in the crash report are not directly implemented in my code?

  2. What do the + signs with numbers at the end of each line in the crashed thread stand for?

  3. Most Q/A on StackOverflow that ask about SIGSEGV crashes say that they are caused by memory leaks or problems, however how can I have a crash because of a memory problem if I'm using ARC in my iOS project? Isn't ARC supposed to manage all of those things for me?

  4. What should I do if I can't replicate the error / crash?

  5. Is there any way to really read a StackTrace? IS there anything in general that would be helpful for understanding what is happening?

Here is the StackTrace from the Main Thread Crash Report from Crittercism that this question pertains to:

Thread: Unknown Name (Crashed)
0     UIKit                                 0x37307a22 -[UIView(CALayerDelegate) actionForLayer:forKey:] + 138
1     QuartzCore                            0x38fdfff7 -[CALayer actionForKey:] + 75
2     QuartzCore                            0x38fdffa7 _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 59
3     QuartzCore                            0x38fdfe93 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131
4     QuartzCore                            0x38fdab87 _ZN2CA5Layer6setterEj12_CAValueTypePKv + 183
5     QuartzCore                            0x39007057 -[CALayer setBackgroundColor:] + 35
6     UIKit                                 0x3731ef51 -[UIView(Internal) _setBackgroundCGColor:withSystemColorName:] + 1021
7     APP NAME                              0x000a301d 0x00086000 + 118813
8     libdispatch.dylib                     0x3962511f _dispatch_call_block_and_release + 11
9     libdispatch.dylib                     0x39628ecf _dispatch_queue_drain$VARIANT$mp + 143
10   libdispatch.dylib                      0x39628dc1 _dispatch_queue_invoke$VARIANT$mp + 41
11   libdispatch.dylib                      0x3962991d _dispatch_root_queue_drain + 185
12   libdispatch.dylib                      0x39629ac1 _dispatch_worker_thread2 + 85
13   libsystem_c.dylib                      0x3824da11 _pthread_wqthread + 361

解决方案

You need to symbolicate this crash report. Number 7 is the line you will be interested in, but there is no symbol information so the crash report cannot be translated into something useful for you. In order to symbolicate you need the exact code that was used in your app store release. If you have that, then you can reference this answer:

http://stackoverflow.com/a/13280585/1155387

As for the other things:

1) Don't be so quick to assume an internal API bug. Your function obviously changes the background color of a view, which calls various methods internally. It probably got passed an invalid value somehow. Don't be so naive as to think the code you write is the only code ever executed.

2) The + signs indicate the offset of that code inside of the binary object. Not useful for you.

3) You can easily have a memory error with ARC, because ARC only deals with the scope of Objective-C. Any CoreFoundation objects, etc, will not be managed. That's not necessarily what happens here but ARC doesn't mean you have to stop thinking about memory all together.

4) See above

5) See above

这篇关于SIGSEGV SEGV_ACCERR崩溃报告 - 该怎么办?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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