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

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

问题描述

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


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


  2. p> 崩溃的线程中每一行末尾的数字 + 的符号代表什么?


  3. 在StackOverflow上查询有关SIGSEGV崩溃的大多数Q / A表示它们是由内存泄漏或问题引起的,但是 我如何可以发生崩溃如果我在我的iOS项目中使用ARC,会出现内存问题? ARC是否应该为我管理所有这些东西?


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


  5. 有没有办法真正地阅读一个StackTrace?有没有什么一般的,有助于了解发生了什么?


这是从主线程的StackTrace Crashcism的崩溃报告,这个问题涉及:

 线程:未知名称(崩溃)
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 0x3731ef5 1 - [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


解决方案

你需要象征这个崩溃报告。第7号是您将感兴趣的线,但没有符号信息,因此崩溃报告不能被翻译成对您有用的东西。为了符号,您需要您的应用商店版本中使用的确切代码。如果你这样做,那么你可以参考这个答案:



https:/



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:

https://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天全站免登陆