What can this Crashlytics iOS crash log mean? - ios

Question

I am getting some crash logs in Crashlytics for my iOS app and I am stumped as to how to interpret them. I have tried everything I can think of in my app to create a crash, and have been unable to create one that will result in a stack trace like the following:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x397e6b26 objc_msgSend + 5
1 Foundation 0x2fcc7f8d -[NSError dealloc] + 60
2 libobjc.A.dylib 0x397f6b0b objc_object::sidetable_release(bool) + 174
3 Foundation 0x2fd241f5 -[NSFilesystemItemRemoveOperation dealloc] + 60
4 libobjc.A.dylib 0x397f6b0b objc_object::sidetable_release(bool) + 174
5 libobjc.A.dylib 0x397e8007 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
6 CoreFoundation 0x2f2de981 _CFAutoreleasePoolPop + 16
7 UIKit 0x31b1624d _wrapRunLoopWithAutoreleasePoolHandler + 36
8 CoreFoundation 0x2f3761cd __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
9 CoreFoundation 0x2f373b71 __CFRunLoopDoObservers + 284
10 CoreFoundation 0x2f373eb3 __CFRunLoopRun + 730
11 CoreFoundation 0x2f2dec27 CFRunLoopRunSpecific + 522
12 CoreFoundation 0x2f2dea0b CFRunLoopRunInMode + 106
13 GraphicsServices 0x34005283 GSEventRunModal + 138
14 UIKit 0x31b82049 UIApplicationMain + 1136
15 Pocket Linesman 0x000d5a8b main + 17 (main.m:17)
Would anyone know how I can go about interpreting the cause of this stack trace? It seems that something is occurring when I am deleting an object in my app from the file system, but I am not 100% sure.

Answer 1

We can see in the backtrace _CFAutoreleasePoolPop.
It means that the crash occurred while the autorelease pool of the current run loop was trying to release an object that was marked for autorelease...
Usually, it means that an autoreleased object was released manually.
Imagine the following:
{
NSObject * o;
o = [ [ [ NSObject alloc ] init ] autorelease ];
[ o release ];
}
The o object here has a retain count of 1, and is marked for autorelease, so the current instance of the autorelease pool will send it a release message next time it's drained.
So the manual call to release, which is wrong, won't produce a crash, as the object is still leaving yet. But the object will then be deallocated, leaving the autorelease pool with a reference to a deallocated object.
When the pool is drained, it will then try to send a release message to that invalid reference, and your app will crash.

Answer 2

By the internal NSFilesystemItemRemoveOperation being deallocated, I would guess that you're dealing with problematic memory management around NSFileManager's removeItemAtPath:error:. Are you making this call anywhere in your code?