SIGSEGV SEGV_ACCERR碰撞报告-该怎么办

Question

我刚刚在AppStore上发布了一个带有Critterism崩溃报告的应用程序，我收到了不少与SIGSEGV错误有关的崩溃报告。Critterism给了我一个StackTrace和一些关于使用统计的方便细节，等等。然而，我仍然被这些符号化的堆栈跟踪弄糊涂了。我对这类东西有一些一般性的问题

1. 据我所知，堆栈跟踪中的许多类和方法甚至没有在我的应用程序中使用，这让我相信这些崩溃是由苹果的私有API造成的。看看这个问题底部附近的堆栈跟踪如果崩溃报告中的所有方法和类都没有直接在我的代码中实现，我如何判断是什么导致我的应用程序崩溃

2. 崩溃线程中每行末尾带有数字的+符号代表什么

3. StackOverflow上大多数询问SIGSEGV崩溃的问答都说它们是由内存泄漏或问题引起的，然而如果我在iOS项目中使用ARC，我怎么会因为内存问题而崩溃难道ARC不应该为我管理所有这些事情吗？

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

5. 有什么方法可以真正读取StackTrace吗？总的来说，有什么有助于理解正在发生的事情吗？

这是Critterism主线程崩溃报告中的StackTrace，该问题与有关

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

Answer 1

您需要将此崩溃报告符号化。编号7是您感兴趣的行，但没有符号信息，因此无法将故障报告转换为对您有用的内容。为了进行符号化，您需要应用商店版本中使用的确切代码。如果你有，那么你可以参考这个答案：

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

至于其他事情：

1) 不要那么快地假设内部有API错误。您的函数显然会更改视图的背景颜色，视图在内部调用各种方法。它可能以某种方式传递了一个无效值。不要天真地认为你编写的代码是唯一执行过的代码。

2) +符号表示二进制对象内部代码的偏移量。对你没用。

3) ARC很容易出现内存错误，因为ARC只处理Objective-C的范围。将不会管理任何CoreFoundation对象等。这不一定会发生在这里，但ARC并不意味着你必须停止思考记忆。

4) 参见以上

5) 参见以上

Answer 2

我愿意你做这样的事情：

CALayer *layer = [CALayer layer];
layer.delegate = self;

然后，在对CALayer的最后一个引用被删除之前，您的对象"self"被解除分配。委托属性不包含对您设置为layer.delete值的对象的引用。这与ARC无关(ARC不会神奇地修复应用程序中所有指针的使用)。

所以，首先要做的是查看设置CALayer委托的代码，并确保在您的"self"对象被释放时将该委托ref设置回nil。这将打破CALayer和您的对象之间的关联。一般来说，你应该将你的dsym上传到Critterism，但在这种情况下，这无关紧要。