SIGSEGV SEGV_ACCERR 崩溃报告 - 怎么办？

Posted 2023-02-24

【中文标题】SIGSEGV SEGV_ACCERR 崩溃报告 - 怎么办？

【英文标题】：SIGSEGV SEGV_ACCERR Crash Reports - What to do?

【发布时间】：2012-11-27 11:44:34

【问题描述】：

我刚刚在 AppStore 上发布了一个带有 Crittercism 崩溃报告的应用程序，我收到了很多与 SIGSEGV 错误有关的崩溃报告。 Crittercism 给了我一个 StackTrace 和一些关于使用统计的方便细节，等等。然而，我仍然对这些符号化的堆栈跟踪感到困惑。关于这种事情，我一般有几个问题-

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

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

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

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

有没有办法真正读取 StackTrace？有什么总体上有助于了解正在发生的事情吗？

这是来自 Crittercism 的主线程崩溃报告中的 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

【参考方案1】：

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

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

至于其他：

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

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

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

4) 见上文

5) 见上文

【参考方案2】：

我愿意成为你做这样的事情：

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

然后你的对象“self”在最后一个对 CALayer 的引用被删除之前被释放。委托属性不包含对您设置为 layer.delegate 值的对象的引用。这与 ARC 无关（ARC 不会神奇地修复您的应用中使用的所有指针）。

因此，首先要做的是查看设置 CALayer 委托的代码，并确保在您的“self”对象被释放时将此委托 ref 设置回 nil。这将破坏 CALayer 和您的对象的关联。一般来说，您应该将您的 dsym 上传到 Crittercism，但在这种情况下并不重要。