Подтвердить что ты не робот

EAAcessory errors при закрытии сессии с iOS 6.0 GM

Существует устройство MFI, которое подключено к iPhone 4S (6.0 GM) или iPad (6.0 GM) через Bluetooth (2.1 + EDR). Проект был построен на Xcode 4.5 GM. Когда приложение получит EAAccessoryDidDisconnectNotification, оно отправит сообщение [_eaSessionController closeSession];. Все это сработало хорошо в iOS 5.1.1 или более раннем. Но на iOS6 с этим сообщением я получил журналы следующим образом:

-[NSCondition dealloc]: condition (<NSCondition: 0x2e5640> '(null)') deallocated while still in use
Break on _NSLockError() to debug.

Любые идеи?

4b9b3361

Ответ 1

В iOS 6.1+ таких проблем нет. Чтобы исправить это для iOS 6.0 и iOS 6.0.1, используйте следующее решение:

Обратите внимание: это только временное решение, позволяющее вашим пользователям с iOS 6.0 и 6.0.1 продолжать использовать ваше приложение.

Существует простой взлом, чтобы избежать сбоев приложений: просто создайте новую категорию и переопределите метод dealloc (NSCondition) для iOS 6.0 и iOS 6.0.1:

#import "NSCondition+LeakDealloc.h"
#import <objc/runtime.h>

@implementation NSCondition (LeakDealloc)

- (void) safeDealloc
{
    float sVersion = [[[UIDevice currentDevice] systemVersion] floatValue];
    if (sVersion < 6.0 || sVersion >= 6.1)
    {
        [self safeDealloc];
    }
}

+ (void) load 
{
    method_exchangeImplementations(class_getInstanceMethod(self, @selector(dealloc)), class_getInstanceMethod(self, @selector(safeDealloc)));
}

@end

Это решение делает новую утечку, после 20-минутных тестов и около 50 инструментов BG/FG swithces показывает 10 утечек NSCondition (960 байт), НО НИКАКОГО сбоя!

Ответ 2

Я столкнулся с той же проблемой. Это предупреждение вызывается при вызове [NSStream close] после получения EAAccessoryDidDisconnectNotification. Также должен быть обмен данными между двумя устройствами непосредственно перед отключением.

Разрыв на _NSLockError покажет, что в момент освобождения объекта некоторые из потоков, порождаемых внешней инфраструктурой аксессуаров, ждут на условиях. Один из них, конечно, ждет при условии освобождения, что объясняет предупреждение, брошенное на консоль.

Я также заметил, что количество потоков, созданных внешней инфраструктурой аксессуаров, продолжает расти каждый раз, когда аксессуар отключается, затем соединяется, и они, кажется, просто просачиваются.

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

Мне удалось воспроизвести проблему, используя базовый образец, в котором потоки запланированы в основном потоке, чтобы избежать управления потоками внутри приложения. Я считаю, что это ошибка вспомогательного управления на iOS 6, о которой должно знать Apple. Я сообщу об этом и дождусь, что они скажут.

Между тем, я задаюсь вопросом, удалось ли кому-либо из вас решить этот прогресс.

Спасибо,

Ответ 3

Проблема исправлена ​​в iOS 6.1. Больше нет утечек NSCondition или внешних аксессуаров. Apple, похоже, правильно исправила проблему.

Ответ 4

О, мы только что видели почти такой же журнал сбоев.

Наше устройство взаимодействует с iPhone, используя bluetooth и USB (iAP). Когда вдруг вытащите USB-кабель для док-станции, наше приложение разбилось. Итак, мы предполагаем, что эта проблема связана с EAAccessary.

Но мы пока не знаем четкой причины. Мы никогда не видели эту проблему в нашем iOS5.1 или ealier, как вы.