Question

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

堆栈跟踪中的许多类和方法甚至都没有在我的应用程序中使用（据我所知），这使我相信这些崩溃是由Apple的私有API引起的。看一下这个问题底部附近的Stack Trace。 如果我的代码中没有直接实现崩溃报告中的所有方法和类，我该怎么知道我的应用程序崩溃了什么？
崩溃线程中每一行末尾的+符号代表什么？
StackOverflow上关于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

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;

然后你的对象“self”在最后一次删除CALayer之前被解除分配。委托属性不保存对您设置为layer.delegate值的对象的引用。这与ARC无关（ARC并没有神奇地修复你应用中的所有指针使用）。

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

SIGSEGV SEGV_ACCERR崩溃报告 - 怎么办？

2 个答案: