IOS 9 Сбой в _prepareForCAFlush с EXC_BAD_ACCESS KERN_INVALID_ADDRESS

С выпуском iOS 9 мы видим несколько отчетов о сбоях, которые, как представляется, являются ошибкой со стороны Apple в iOS 9. Это происходит в разных типах устройств (iPhone, iPad и iPod). Я ищу, чтобы узнать, почему это может произойти, и если есть что-то, что я могу сделать, чтобы обойти это. Этот стек сообщается через нашу систему отчетов о сбоях (Crashlytics), поэтому, к сожалению, у меня нет воспроизводимых шагов или кода, но я постараюсь ответить на любые вопросы как можно лучше. Стек выглядит следующим образом:

Thread : Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x34a27ad6 objc_msgSend + 21
1  CoreFoundation                 0x230d3db9 -[__NSArrayM dealloc] + 148
2  libobjc.A.dylib                0x34a34f67 objc_object::sidetable_release(bool) + 150
3  libobjc.A.dylib                0x34a353a9 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 388
4  CoreFoundation                 0x230cbfa9 _CFAutoreleasePoolPop + 16
5  UIKit                          0x27523cd9 _prepareForCAFlush + 312
6  UIKit                          0x2752886b _beforeCACommitHandler + 10
7  CoreFoundation                 0x2317a509 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
8  CoreFoundation                 0x2317880d __CFRunLoopDoObservers + 280
9  CoreFoundation                 0x23178c3f __CFRunLoopRun + 958
10 CoreFoundation                 0x230cc249 CFRunLoopRunSpecific + 520
11 CoreFoundation                 0x230cc035 CFRunLoopRunInMode + 108
12 GraphicsServices               0x2c182ad1 GSEventRunModal + 160
13 UIKit                          0x272e18a9 UIApplicationMain + 144
14 APPNAMEHERE                    0x000ec967 main (main.m:14)

Ответ 1

Мы столкнулись с сбоем с аналогичной трассировкой стека, и после долгого расследования выяснилось, что это связано с другой катастрофой; исправления, которые также исправили это, однако я все еще не уверен, как связаны две аварии.

Ниже приведены сведения о другом сбое:

У нас был вызов функции в одном из наших методов, таких как

AudioServicesAddSystemSoundCompletion(self.soundID,  
                                      [[NSRunLoop currentRunLoop] getCFRunLoop],  
                                      kCFRunLoopDefaultMode,  
                                      AudioServicesSystemSoundCompletion,  
                                      (void *)CFBridgingRetain(self));

где AudioServicesSystemSoundCompletion выглядел как

void AudioServicesSystemSoundCompletion(SystemSoundID ssID,  void *clientData) {  
     AudioServicesRemoveSystemSoundCompletion(ssID);  
     CFRelease(clientData);  
}

Выполнение вызова этой функции два или более раз одновременно приводило к сбою приложения. Мы исправили это, передав NULL вместо (void *) CFBridgingRetain (self) и удалив CFRelease (clientData); линия.

Так как это исправление, мы больше не видим сбоя '_prepareForCAFlush'.

Также обратите внимание, что в соответствии с Crashlytics у устройства было очень много памяти при каждом воспроизведении сбоя.

Надеюсь, это поможет!

Ответ 2

Для меня проблема заключалась в том, что я показывал и отклонял клавиатуру, когда приложение было сведено к минимуму.

    [self.textView becomeFirstResponder];
    [self.textView resignFirstResponder];

Я выполнил вышеуказанный код в событии applicationWillResignActive. удалив этот код, исправил сбой.

Ответ 3

Я тоже сталкиваюсь с этой проблемой, и я думаю, что нашел то, что может вызвать ее. Вы, ребята, случайно используете SDWebImage? Потому что это единственное место, где я обнаружил, что CFRunLoopRun() вызывается, а также другие люди жаловались: Dead thread ticket → Ошибка приложения

Ответ 4

Кажется, это касается только устройств с 32-разрядными процессорами A5 и A6 - iPod 5th Gen, iPhone 4S/5/5C, iPad 2/Mini). На нашей стороне тоже не воспроизводится. Эти сбои начались и ускорились с выпуском и внедрением iOS 9. iOS v9.0.1, похоже, не исправляет его.