fuite fuite [NSURLConnection sendSynchronousRequest: theRequest returningResponse: néant erreur: néant]

Question

J'ai une fuite dans returnData = [NSURLConnection sendSynchronousRequest: theRequest returningResponse: néant erreur: néant];

Le dessous est le code que je utilise

NSString* curl = @"https://Some Url?ticket="; 
curl = [curl stringByAppendingString:self.ticket]; 
curl = [curl stringByAppendingString:@"&apikey=hjgajgfjaghjf&XMLString="]; 
curl = [curl stringByAppendingString:stringB]; 
curl = [curl stringByReplacingOccurrencesOfString:@"\n" withString:@""]; 
NSURL *finalURL = [NSURL URLWithString:curl]; 

    NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:finalURL cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:10]; 
    [theRequest setHTTPMethod:@"POST"]; 

    NSData* returnData= [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil]; 

Quelqu'un peut-il me dire pourquoi je reçois la fuite dans returnData Je relased le returnData et essayé encore, mais je reçois.

Merci Vous

Answer 1

À partir du code que vous avez posté, il n'y a pas de fuite. Il est possible que lorsque vous retournez returnData, l'appelant le conserve et oublie de le libérer, mais tous les objets dans l'extrait de code que vous avez fourni sont auto-libérés et seront libérés à la fin du cycle actuel.

Quelques choses que je peux penser:

1. Êtes-vous en cours d'exécution peut-être cela dans un thread d'arrière-plan (via performSelectorInBackground: withObject: ou avec une allocation explicite NSThread) et oublier de créer, puis vider un NSAutoreleasePool autour du code?

2. Vous pouvez avoir de la mémoire attachée dans le cache NSURLConnection. Vous n'avez pas mentionné ce qui vous amène à penser que la fuite de données a été détectée, mais s'il s'agit simplement d'une perte de mémoire dans cette zone (contrairement à l'instrument Leaks qui balisait spécifiquement l'objet returnData), vous pouvez libérer de la RAM. cache NSURLConnection explicitement avec quelque chose comme [[NSURLCache sharedURLCache] removeAllCachedResponses];

3. Bien que lié à aucun réel il y a fuite, il serait un peu plus efficace pour construire votre chaîne d'URL à l'aide NSString-stringWithFormat: au lieu des plusieurs appels à -stringByAppendingString:. Encore une fois, tout est auto-libéré, donc il n'y a pas de fuite dans la gestion des chaînes, mais vous créez moins d'objets temporaires et réduisez votre utilisation maximale de la mémoire avant le prochain vidage NSAutoreleasePool.

Le premier endroit où je chercherais une solution serait dans l'appelant de ce code. Les chances sont plutôt bonnes de conserver la valeur de retour de cette méthode et de ne pas la libérer correctement à un moment donné. @property peut également être affecté à la propriété -dealloc. Les instruments vous indiqueront l'emplacement auquel la fuite de mémoire a été attribuée pour la première fois, mais elle n'a aucun moyen de savoir où la fuite s'est réellement produite. la dernière variable contenant le pointeur est écrasée ou hors de portée.

Si ce n'est déjà fait, essayez de compiler votre code avec la fonction Build and Analyze de Xcode. L'analyseur statique CLANG exécuté par cette fonction peut généralement déterminer où votre dernière référence est perdue plus que l'analyse dynamique d'exécution dans Instruments.

Bonne chance avec le suivi de cela! Les fuites ne sont jamais amusantes ....

Answer 2

J'ai eu l'inverse du problème. Je n'ai pas réussi à l'effacer. Alors voici ce que j'ai fait: j'ai ajouté une autre paire qui sera toujours différente ce qui rendra l'URL toujours un peu différente.J'ai ajouté:

[...] 

curl = [curl stringByAppendingString:@"&hello=hello"]; 

curl = [curl stringByAppendingString:nowStr]; 

where nowStr: 

NSDate *now = [NSDate date]; 

NSString * nowStr = [NSString stringWithFormat:@"%@", now]; 

nowStr = [nowStr stringByReplacingOccurancesOfString:@" " withString:@""]; 

nowStr = [nowStr stringByReplacingOccurancesOfString:@"+" withString:@""]; 

Je suis sûr que je devrais avoir utiliser quelque chose à voir avec un nombre aléatoire et peut-être que je le ferai plus tard.