NSXMLParser Leaking

Tengo el siguiente código que se filtra. Instruments dice que es el objeto rssParser el que está goteando. I "refrescar" la fuente XML y se ejecuta el bloque y se escapa ....NSXMLParser Leaking

file.h

@interface TestAppDelegate : NSObject <UIApplicationDelegate> { 

    NSXMLParser *rssParser; 

}

file.m

NSData *data = [ NSURLConnection sendSynchronousRequest:request returningResponse: nil error: nil ]; 
    rssParser = [[NSXMLParser alloc] initWithData:data]; 
    [rssParser setDelegate:self]; 
    [rssParser setShouldProcessNamespaces:NO]; 
    [rssParser setShouldReportNamespacePrefixes:NO]; 
    [rssParser setShouldResolveExternalEntities:NO]; 
    [rssParser parse]; 
    [rssParser release];

Imagen de fuga ....

alt text http://www.shipfinder.co.uk/images/memoryleak.png

Fuente

2009-10-21 Lee Armstrong

Tenga en cuenta que las tres sentencias setShould * son todas predeterminadas en NO, por lo que puede eliminarlas de su código. –

Apple ha de volver a mí y esto es un error # 6469143

Parece que piensan resolver el 4,0

Fuente

2010-01-22 06:44:07

¿Has recibido alguna respuesta de Apple sobre este error? –

Estoy obteniendo la misma pérdida que esta fuga reparada en 4.0 – kiri

Bueno, todavía lo veo en el SDK de iOS4. Todavía no descargué la última – philsquared

la causa más probable es que uno de sus métodos de delegado retiene el analizador. ¿Haces algo con tu parámetro analizador en los métodos delegados?

¿Obtiene una fuga cada vez que actualiza?

Si este es el único lugar donde se usa rssParser, ¿por qué lo hace un ivar? Si necesitas un ivar, no puedo enfatizar lo importante que es usar siempre los accesorios para ellos y nunca acceder a ellos directamente. La mejor forma de evitar fugas de memoria es utilizar accesos para sus ivars.

Además, nunca suelte algo sin configurarlo inmediatamente en otra cosa (generalmente nula). Su lanzamiento de rssParser anterior es un bloqueo que está por ocurrir porque ahora tiene un puntero a la memoria potencialmente no asignada.

Fuente

2009-10-21 07:00:08

Sí, me sale una fuga cada vez, hice los cambios que describe como sí, ¡no debería ser un ivar! ¡Todavía con goteras! –

¿Tiene Xcode 3.2 (de SnowLeopard)? La herramienta Construir y Analizar es muy buena para encontrar fugas simples. –

Sí, ya lo intenté. –

Parece que este es un problema bien conocido. Vea aquí NSURLConnection leaking. Sin embargo si se establece lo siguiente antes de iniciar la filtración analizador se detiene:

[[NSURLCache sharedURLCache] setMemoryCapacity:0]; 
[[NSURLCache sharedURLCache] setDiskCapacity:0]; 
NSXMLParser *parser = [[NSXMLParser alloc]initWithContentsOfURL:URL];

Fuente

2009-11-09 17:50:50 leviathan

En realidad, Apple me respondió y este problema ya está registrado como 6469143. No estoy seguro de cuándo lo solucionarán. ¡Todavía gotea cambiando a tu manera de hacerlo también! –

Lo solucioné usando el método descrito en this post.

Es una solución, pero funciona.

En otra nota, he encontrado que Instruments funciona de manera confiable en Lion/Xcode 4.1 si siempre lo ejecuta en el dispositivo, a diferencia del simulador. En el simulador, parece tener un demonio de un tiempo asociado al proceso.

La implementación de NSXMLParser parece tener una fuga natural. Hay otra filtración proveniente de esta biblioteca en otra parte de mi aplicación que necesito ver si puedo localizarla. Esa es una llamada asincrónica, y esta solución no parece funcionar para eso.

Fuente

2011-09-19 12:20:35

Respuesta

Cuestiones relacionadas