Go through it:
0 MyAppName 0x0013faba testflight_backtrace + 382 1 MyAppName 0x00140708 TFSignalHandler + 264
This is TestFlight. This happens after a failure occurs, so this, of course, is not the reason.
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
This is the moment when we are faced with collapse. Sigtramp is a trampoline signal. This is a fancy way of saying, "I caught a signal (accident), and now I'm going to bounce elsewhere in the code."
3 Foundation 0x33750d1c -[NSError dealloc] + 60
Oh. It is important. We crashed on releasing a NSError . This means that NSError was too released or underexposed.
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168 5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16 6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
Sadly ... this manifested itself by omitting the pool of abstracts. This means that the real mistake can be far from here. But at least we know the type of object. NSZombies can be useful to try to find a specific object.
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
And the auto-advertisement pool merged while saving the MOC. This suggests that this is probably related to your Core Data code. This, at least, is where you looked first.
What you need to remember:
- An error in your code is almost certain.
- If it's not in your code, maybe it's in Magical Record
- Do not assume that this is in Core Data. This is the least likely place for an error indicated on this stack.
Here's the weirdest part - if the user has an older version of the application and installs the update (distributed via Test Flight), they get this error.
However, if they first uninstall the old application and install the update, an error does not occur.
Maybe in your update code. Most likely in master data transfer materials. Audit every use of NSError in this area of code. Eliminate all warnings from the compiler and analyzer. And try NSZombies if it is playing.