Ios 解释iPhone崩溃日志/堆栈跟踪

我正在使用，收到了几份与此相同的碰撞报告。然而，我很难理解这一点，从报告中可以看出坠机的根本原因是什么

Exception

SIGSEGV
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60...

Exception reason

SIGSEGV

Stacktrace

0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
8 MyAppName 0x000b7168 MR_swapMethodsFromClass + 18076
9 CoreData 0x35e0dbc0 developerSubmittedBlockToNSManagedObjectContextPerform + 88
10 libdispatch.dylib 0x335974b6 _dispatch_client_callout + 22
11 libdispatch.dylib 0x33598dca _dispatch_main_queue_callback_4CF$VARIANT$up + 226
12 CoreFoundation 0x31e79f3a __CFRunLoopRun + 1290
13 CoreFoundation 0x31decebc CFRunLoopRunSpecific + 356
14 CoreFoundation 0x31decd48 CFRunLoopRunInMode + 104
15 GraphicsServices 0x36e092ea GSEventRunModal + 74
16 UIKit 0x320db2f8 UIApplicationMain + 1120
17 MyAppName 0x00099122 main (main.m:17)
18 MyAppName 0x000990d7 start + 39

其他详情：

• 用户报告此崩溃发生在应用程序启动后1-2秒
• 该应用程序使用核心数据和（MR_swapMethodsFromClass方法就是从中产生的）
• 当从运行各种iOS版本（iOS 5.1、6.0、6.1）的Xcode（iPhone3GS、iPhone4或iPhone5）运行时，我无法在任何测试设备上重现此问题

编辑

还在努力解决这个问题。。。我已经能够重新创建它（但没有附加调试器）

这里是最奇怪的部分——如果用户有一个较旧版本的应用程序并安装了一个更新（通过试飞分发），他们会得到这个错误

但是，如果他们先删除旧应用程序并安装更新，则不会发生错误。

让我们来了解一下：

0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264

那是试飞。这是在坠机事件发生之后，所以这肯定不是原因

2 libsystem_c.dylib 0x32862e92 _sigtramp + 42

这就是我们撞车的地方。“sigtrimp”是信号“蹦床”。这是一种奇特的说法，“我捕捉到一个信号（崩溃），现在我要跳转到代码中的其他地方。”

啊。这很重要。我们在解除分配

n错误时崩溃。这意味着
n错误
被过度发布或保留不足

4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122

可悲的是…它在排空自动释放池时出现。这意味着真正的bug可能离这里很远。但至少我们知道物体的类型。NSZombies可用于尝试查找特定对象

7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210

在MOC保存期间，自动释放池正在排空。这表明它可能与您的核心数据代码有关。至少你应该先看看

要记住的是：


这个bug几乎肯定存在于您的代码中
如果它不在你的代码中，它可能在魔法记录中
不要假设它在核心数据中。这是给定此堆栈的bug最不可能出现的位置

这里是最奇怪的部分——如果用户有一个较旧版本的应用程序并安装了一个更新（通过试飞分发），他们会得到这个错误

但是，如果他们首先删除旧应用并安装更新，则不会发生错误

可能在你的升级代码中。最有可能是在核心数据迁移方面。审核该代码区域中
n错误的每次使用。消除所有编译器和分析器警告。如果可以复制，请尝试NSZombies。
您应该尝试向数据模型添加模型版本。它对我起了作用，我也有一个类似的与魔法唱片有关的问题。
你需要将坠机报告象征化。现有的很多话题都在讨论如何做到这一点。苹果对此也有技术说明（或问答）。搜索文档。我以为它是象征性的。。。？也就是说，方法名称显示在
MyAppName
——即第8行
MR_swapMethodsFromClass
？（我还将.dSYM上传到TestFlight，据说这允许它在开发者不需要这样做的情况下进行符号化）我在这里感到困惑吗？对不起，你是对的。我看得太快了。这似乎是某种内存管理问题。保存托管对象上下文时，在自动释放池的排空过程中，取消分配
n错误
对象时出现问题。由于这一切都是从MagicalRecords代码开始的，您可能需要查看他们的支持网站。也许您可以使用更新的版本，或者这是一个已知的问题。我有一个非常类似的错误，您是否设法解决了这个问题？
MR_swapMethodsFromClass+18076
在我看来很奇怪；函数不可能生成18k的机器代码，也不可能调用
save:
。我的猜测是：（a）这里涉及到其他一些库，可能是一个没有符号信息的库，它调用
save:
和
MR_swapMethodsFromClass
恰好是具有符号名称的最接近的符号，或者（b）堆栈损坏；不管怎样，
MR_swapMethodsFromClass
都是在转移注意力。我想看看还有什么可以调用
save:
和/或收听NSManagedObjectContextDidSave通知。太棒了，谢谢Rob。你对“可能在升级代码中”的猜测是正确的。tramp=trampoline很有用，但我之所以给这个a+1是因为它是一个非常棒的答案。这帮助mee追踪到我的应用程序问题！谢谢
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210