Что может означать краш-журнал Crashlytics iOS?

Question

Я получаю некоторые журналы сбоев в Crashlytics для моего приложения iOS, и я в тупике, как их интерпретировать. Я попробовал все, что я могу думать в мое приложение, чтобы создать аварию и не смогли создать что приведет к трассировки стека, как следующее:

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) 

ли кто-нибудь знает, как я могу идти о толковании причина этой трассировки стека? Кажется, что-то происходит, когда я удаляю объект в своем приложении из файловой системы, но я не уверен на 100%.

Answer 1

Мы можем видеть в обратной линии _CFAutoreleasePoolPop.

Это означает, что авария произошла в то время как autorelease пул текущего цикла выполнения пытается освободить объект, который был отмечен для autorelease ...

Как правило, это означает, что autoreleased объект был освобожден вручную.
Представьте себе следующее:

{ 
    NSObject * o; 

    o = [ [ [ NSObject alloc ] init ] autorelease ]; 

    [ o release ]; 
} 

Объекта o здесь есть сохранить кол 1 и помечается для autorelease, поэтому текущий экземпляр autorelease пула будет посылать ему в следующий раз release сообщения это дренированный.

Таким образом, ручной вызов release, что не так, не приведет к сбою, поскольку объект все еще уходит. Но тогда объект будет освобожден, оставив пул авторесурсов со ссылкой на освобожденный объект.

Когда пул сливается, он попытается отправить сообщение release на эту неверную ссылку, и ваше приложение выйдет из строя.

Answer 2

По внутреннему NSFilesystemItemRemoveOperation, который будет освобожден, я бы предположил, что вы имеете дело с проблемным управлением памятью NSFileManager's removeItemAtPath:error:. Вы делаете этот звонок в любом месте своего кода?