如何在生产应用程序中找到根本原因崩溃：com.apple.main-thread？

Posted 2023-03-06

【中文标题】如何在生产应用程序中找到根本原因崩溃：com.apple.main-thread？

【英文标题】：How to find root cause Crashed: com.apple.main-thread in production app?

【发布时间】：2015-06-15 21:52:56

【问题描述】：

我有一份来自 Crashlytics 的报告：

Thread : Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x000000019503fbd0 objc_msgSend + 16
1  CoreFoundation                 0x00000001836e5458 CFRelease + 524
2  CoreFoundation                 0x00000001836f1a18 -[__NSArrayM dealloc] + 152
3  libobjc.A.dylib                0x0000000195045724 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
4  CoreFoundation                 0x00000001836e9074 _CFAutoreleasePoolPop + 28
5  Foundation                     0x000000018461a588 -[NSAutoreleasePool release] + 148
6  UIKit                          0x00000001882b4460 -[UIApplication _run] + 588
7  UIKit                          0x00000001882aefac UIApplicationMain + 1488

有什么办法可以解决这个问题吗？它发生在客户设备上，所以我没有机会重现它。

【问题讨论】：

我也收到了来自 Crashlytics 的相同崩溃报告。您找到上述崩溃的根本原因了吗？

【参考方案1】：

对于像这样的崩溃，如果崩溃是可重现的，请在项目的环境变量中打开 NSZombies。这将使已释放的对象（僵尸）保持活动状态，并且当其中一个收到消息时，调用者和消息将被捕获到崩溃的对象上。

完成后将其关闭，因为它可能会由于没有为僵尸跟踪而释放的对象而阻塞应用程序的内存。

【参考方案2】：

一些逻辑代码需要在后台运行。您需要尝试调试代码在哪里出错，然后添加此代码

DispatchQueue.main.async(execute: 
     // your code
)

【讨论】：

您的代码没有启动后台线程，而是在主线程上执行。

【参考方案3】：

这里已经回答了：objc_msgSend [__NSArrayM dealloc] crash report sometimes from Crashlytics

基本上，将您的 Crashlytics 框架升级到 3.0.9 之前的版本。崩溃发生在崩溃报告框架本身中。