objective c - EA Errores de error al cerrar sesión con iOS 6.0 GM

objective-c ios6

Question

Hay un dispositivo MFI que está conectado al iPhone 4S (6.0 GM) o al iPad (6.0 GM) a través de Bluetooth (2.1 + EDR). El proyecto fue construido en Xcode 4.5 GM. Cuando la aplicación obtiene EAAccessoryDidDisconnectNotification , enviará el mensaje [_eaSessionController closeSession]; . Todo esto funcionó bien en iOS 5.1.1 o Earler. Pero en iOS6 con este mensaje obtuve registros de la siguiente manera:

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

¿Algunas ideas?

Answer 1

Oh, acabamos de ver casi el mismo registro de bloqueo.

Nuestro dispositivo se comunica con iPhone, usando bluetooth y USB (iAP). Cuando, de repente, extrae el cable de conexión USB, nuestra aplicación se cuelga. Por lo tanto, creemos que este problema está relacionado con EAAccessary.

Pero aún no hemos tenido una razón clara. Nunca vimos este problema en nuestro iOS5.1 o ealier one, como usted.

Answer 2

Me encontré con el mismo problema. Esta advertencia se produce al llamar a [NSStream cerrar] al recibir una EAAccessoryDidDisconnectNotification. También debe haber algún intercambio de datos entre los dos dispositivos justo antes de la desconexión.

Al activar _NSLockError, se mostrará que, en el momento en que se desasigna el objeto, algunos de los subprocesos generados por el marco de acceso externo están esperando condiciones. Uno de ellos ciertamente espera con la condición de que se libere, lo que explica la advertencia lanzada en la consola.

También noté que el número de subprocesos creados por el marco de accesorios externo sigue creciendo cada vez que el accesorio se desconecta y luego se conecta, y parece que solo están goteando.

Me parece que de alguna manera, el marco accesorio externo no libera adecuadamente los recursos que asigna, lo que resulta en mucho desorden. Uno de los efectos posteriores de esto son los bloqueos que ocurren dentro de uno de esos hilos filtrados durante una llamada a OSAtomicCompareAndSwap64.

Logré reproducir el problema usando una muestra básica en la cual las secuencias están programadas en el hilo principal para evitar cualquier administración de subprocesos dentro de la aplicación. Creo que es un error de administración de accesorios en iOS 6 que Apple debería tener en cuenta. Lo reportaré y esperaré por lo que tengan que decir.

Mientras tanto, me pregunto si alguno de ustedes ha logrado avanzar en esto.

Gracias,

Answer 3

El problema se ha solucionado en iOS 6.1. No hay más fuga NSCondition o hilos de accesorios externos. Apple parece haber solucionado el problema correctamente.

Answer 4

No hay tal problema en iOS 6.1+. Para solucionar esto, para iOS 6.0 e iOS 6.0.1, use la siguiente solución:

Tenga en cuenta : esta es la única solución temporal que permite a sus usuarios con iOS 6.0 y 6.0.1 continuar usando su aplicación.

Hay un truco simple para evitar bloqueos de aplicaciones: simplemente cree una nueva categoría y anule el método dealloc (NSCondition) para iOS 6.0 e 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

Esta solución hace una nueva fuga, después de pruebas de 20 minutos y unos 50 instrumentos SWith de BG / FG muestran 10 fugas de NSCondition (960 Bytes), ¡PERO nadie falla!