SIGSEGV SEGV_ACCERR 崩溃报告 - 怎么办? [英] SIGSEGV SEGV_ACCERR Crash Reports - What to do?
问题描述
我刚刚在 AppStore 上发布了一个带有 Crittercism 崩溃报告的应用程序，我收到了很多与SIGSEGV 错误.Crittercism 给了我一个 StackTrace 和一些关于使用统计的方便细节，等等.然而，我仍然对这些符号化的堆栈跟踪感到困惑.关于这种事情，我一般有几个问题-
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 -
Stack Trace 中的许多类和方法甚至都没有在我的应用程序中使用(据我所知)，这让我相信这些崩溃是由于 Apple 的私有 API 造成的.看看这个问题底部附近的堆栈跟踪.如果崩溃报告中的所有方法和类都没有直接在我的代码中实现，我如何知道是什么导致了我的应用程序崩溃?
崩溃线程中每行末尾带有数字的 + 符号代表什么?
What do the + signs with numbers at the end of each line in the crashed thread stand for?
StackOverflow 上大多数询问 SIGSEGV 崩溃的 Q/A 都说它们是由内存泄漏或问题引起的，然而 我怎么会因为内存问题而崩溃如果我在我的 iOS 项目中使用 ARC? 难道 ARC 不应该为我管理所有这些事情吗?
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?
如果无法复制错误/崩溃，我该怎么办?
有没有办法真正读取 StackTrace?有什么总体上有助于了解正在发生的事情吗?
Is there any way to really read a StackTrace? IS there anything in general that would be helpful for understanding what is happening?
这是来自 Crittercism 的主线程崩溃报告中的 StackTrace，该问题与此问题有关:
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
推荐答案
你需要符号化这个崩溃报告.第 7 行是您感兴趣的行，但没有符号信息，因此无法将崩溃报告翻译成对您有用的内容.为了表示您需要在您的应用商店版本中使用的确切代码.如果你有，那么你可以参考这个答案:
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
至于其他:
1) 不要这么快就假设存在内部 API 错误.您的函数显然会更改视图的背景颜色，该视图在内部调用各种方法.它可能以某种方式传递了一个无效值.不要天真地认为您编写的代码是唯一执行过的代码.
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) + 符号表示该代码在二进制对象内的偏移量.对你没用.
2) The + signs indicate the offset of that code inside of the binary object. Not useful for you.
3) ARC 很容易出现内存错误，因为 ARC 只处理 Objective-C 的范围.不会管理任何 CoreFoundation 对象等.这不一定是这里发生的事情，但 ARC 并不意味着你必须停止思考记忆.
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) 见上文
5) 见上文
这篇关于SIGSEGV SEGV_ACCERR 崩溃报告 - 怎么办?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
