2010-03-13 9 views
10

instrumentos que se ejecutan en el dispositivo, que de forma intermitente incurrir en una pérdida de memoria de exactamente 3,5 KB en CFNetwork, el marco responsables de ser "HostLookup_Master :: HostLookup ...."CFNetwork/NSURLConnection fugas

He leído una serie de preguntas re esta cuestión y han tratado por separado lo siguiente para reparar la fuga:

  1. Incluye lo siguiente en applicationDidFinishLaunching:

    NSURLCache * sharedCache = [[NSURLCache alloc] initWithMemoryCapacity: 0 diskCapacity: 0 diskPath: nulo]; [NSURLCache setSharedURLCache: sharedCache]; [release de Cache compartido];

  2. Especificado en urlrequest para no cargar desde la memoria caché local.

Ninguno de los anteriores funcionó. Mi clase que ejemplifica las conexiones no se filtra, ya que sus instancias se liberan cuando los datos se han descargado. Lo he verificado confirmando que los objetos vivos de la clase son 0 utilizando instrumentos.

Cualquier consejo sobre cómo abordar esta fuga sería muy apreciado.

+2

Técnicamente, no se trata de una fuga si la búsqueda del host se está almacenando en la memoria caché, ya que aún se hace referencia y se puede reutilizar. Quiero decir, podría haber una fuga en el código de caché donde nunca lo libera. Si se trata de una fuga, presente un informe de error de Radar con Apple. – lucius

+0

NSURLConnection gotea en el mejor de los casos. Gotea MUCHO cuando se trata de subprocesos múltiples. No me preocuparía una pequeña fuga de información: aprobación de la tienda de aplicaciones. – sehugg

Respuesta

1

esa fuga de memoria 3,5 kb suena familiar, tuvo que cuando se trata con hilos:

@implementation MyClass 
+ (void)login 
{ 
    //MyClass *this = [[MyClass alloc] init]; // MEMORY LEAK 
    MyClass *this = [[[MyClass alloc] init] autorelease]; 
    [NSThread detachNewThreadSelector:@selector(anotherThread) 
          toTarget:this 
          withObject:nil]; 
} 

- (void)anotherThread { 
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
    [self doStuff]; 
    //[self release]; // MEMORY LEAK 
    [pool release]; 
} 
@end 

cada inicio de sesión creado fuga de 3,5 kb. El uso de la liberación automática resolvió el problema.

+0

Para mí, parece un poco incómodo lo que está haciendo, ¿por qué hace esta tarea: MyClass * this = [[[MyClass alloc] init] liberación automática]; "esto" no es lo que normalmente se usa en Obj-C. Tiene sentido que pierdas memoria si no la asignas a uno mismo, que normalmente se usa en Obj-C. Lo que tampoco entiendo es que declares "esto" como una variable local. Si regresa desde el inicio de sesión + (nulo), está fuera del alcance y su puntero se pierde. Lo que haga en [self release] sería enviar mensajes nulos, lo que funciona bien. Entonces está filtrando la variable "this". – GorillaPatch

+0

El inicio de sesión de @GorillaPatch es un método de clase, no un método de instancia, por lo que no se filtra ningún "yo". El objeto creado, que pasa a denominarse "this" (una mala elección del nombre en mi humilde opinión), es el objetivo cuando - (void) anotherThread se invoca, por lo que debe ser lanzado en ese punto. – Tony

+1

@Tony así me confundí con el "esto". Para mí, tendría sentido que el hilo separado se apropie de este objeto y luego lo libere en el método de inicio de sesión + directamente después de generar un nuevo hilo. ¿Qué piensas? – GorillaPatch

1

Parece que Apple podría estar al tanto de la fuga de 3.5k relacionada con el uso de CFNetwork y puede haber sido reported as a bug already.

+1

La presentación de un error en Apple es un poco como sacrificar un pollo. No está seguro si ayuda, pero ciertamente no hace ningún daño. ;-) – GorillaPatch

+0

El pollo podría tener una opinión diferente sobre eso. –