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

Question

我正在使用TestFlight SDK并收到了几个与此相同的崩溃报告。但是，我无法理解它，崩溃的根本原因来自报告？

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秒
• 该应用使用核心数据和MagicalRecord（这是MR_swapMethodsFromClass方法的来源）
• 从运行各种iOS版本（iOS 5.1,6.0,6.1）的Xcode（iPhone 3GS，iPhone 4或iPhone 5）运行时，我无法在任何测试设备上重现此问题

修改

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

这是最奇怪的部分 - 如果用户拥有较旧版本的应用程序并安装更新（通过Test Flight分发），则会出现此错误。

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

Answer 1

让我们一起来看看：

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

那是TestFlight。这是在崩溃发生之后，所以肯定不是原因。

2 libsystem_c.dylib 0x32862e92 _sigtramp + 42

这是我们抓住崩溃的时刻。 “sigtramp”是信号“蹦床”。这是一种奇特的方式，说“我发现了一个信号（崩溃），现在我将反弹到代码中的其他地方。”

3 Foundation 0x33750d1c -[NSError dealloc] + 60

阿。这个很重要。我们在解除分配NSError时崩溃了。这意味着NSError被过度释放或保留不足。

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来说，这是最不可能的地方。

  

这是最奇怪的部分 - 如果用户拥有较旧版本的应用程序并安装更新（通过Test Flight分发），则会出现此错误。

     

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

可能在您的升级代码中。最有可能在Core Data迁移中。审核该代码区域中NSError的每次使用情况。消除所有编译器和分析器警告。并尝试NSZombies，如果它可重现。

Answer 2

您应该尝试将模型版本添加到数据模型中。它对我有用，我有一个类似魔法记录的问题。