Interpreting iPhone Crash Log / Stack Trace - ios

Question

I'm using the TestFlight SDK and have received several crash reports identical to this one. However, I'm having trouble understanding it, and what the underlying cause of the crash is from the reports?
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
Additional details:
Users report this crash happens 1-2 seconds after the app starts
The app uses Core Data and MagicalRecord (which is where the MR_swapMethodsFromClass method comes from)
I can't reproduce this issue on any test devices when running from Xcode (iPhone 3GS, iPhone 4, or iPhone 5) running various iOS versions (iOS 5.1, 6.0, 6.1)
EDIT
Still working on solving this issue... I've been able to recreate it (but not with a debugger attached).
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.

Answer 1

Let's walk through it:
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
That's TestFlight. This is after the crash has happened, so it's certainly not the cause.
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
This is the point at which we caught the crash. "sigtramp" is the signal "trampoline." That's a fancy way of saying "I caught a signal (crash) and now I'm going to bounce to somewhere else in the code."
3 Foundation 0x33750d1c -[NSError dealloc] + 60
Ah. This is important. We crashed while deallocating an NSError. That means the NSError was over-released or under-retained.
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
Sad… it manifested while draining the autorelease pool. That means the actual bug could be a long way from here. But at least we know the type of the object. NSZombies could be of use to try to find the specific object.
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
And the autorelease pool was draining during a MOC save. That suggests it's probably related to your Core Data code. It's at least where you'd look first.
The things to remember are:
The bug is almost certainly in your code.
If it's not in your code, it's probably in Magical Record
Do not assume it is in Core Data. That is the least likely place for the bug given this stack.
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Probably in your upgrade code then. Most likely in the Core Data migration stuff. Audit every use of NSError in that area of code. Eliminate all compiler and analyzer warnings. And try NSZombies if its reproducible.

Answer 2

You should try to add a model version to your data model. It worked for me, i had a similar Magical-Record-related issue.