2009-07-17 7 views
1

Je suis en cours d'exécution une application sur l'iPhone qui effectue les actions suivantes:Fuite de mémoire dans removeItemAtPath: erreur:?

+ (void)performWrite:(NSData *)data { 
    [data retain]; 
    [data writeToFile:@"WriteTest.tst" atomically:YES]; 
    [[NSFileManager defaultManager] removeItemAtPath:@"WriteTest.tst" error:NULL]; 
    [data release]; 
} 

Lors de l'exécution d'instruments, cependant, je vois une fuite dans chaque appel à removeItemAtPath:error, avec la trace suivante à la fuite interne:

9 MyApplication +[StorageUtil performWrite:] 
    8 Foundation -[NSFileManager removeItemAtPath:error:] 
    7 Foundation +[NSFilesystemItemRemoveOperation filesystemItemRemoveOperationWithPath:] 
    6 Foundation -[NSOperation init] 
    5 CoreFoundation +[NSObject new] 
    4 CoreFoundation +[NSObject alloc] 

Cette trace de la pile est prévu comme source à la fois une fuite d'un NSRecursiveLock, et d'un objet _NSOperationData. Donc ce que je me demande c'est si j'utilise mal la méthode removeItemAtPath:error: ou s'il y a vraiment une fuite. J'ai pensé que je vérifierais ici avant de le soumettre à Radar.

Notez que l'argument data adhère correctement au cycle de conservation/libération en dehors de cet appel de méthode. Je ne crois pas que ce soit la source de la fuite.

Répondre

1

La fonction était appelée dans un thread séparé (créé à l'aide de pthread_create()), et en tant que tel n'était pas encapsulé dans un NSAutoreleasePool. La création du pool avant l'appel de la méthode et sa vidange afterwords ont pris soin de la fuite.