Pourquoi les instruments signalent-ils des fuites de mémoire dans ce code?

Question

question rapide, Instruments rapporte une fuite ici ...

MyViewController *myVC = [[MyViewController alloc] initWithNibName:@"myView" bundle:nil];  
[self.navigationController pushViewController:myVC animated:YES]; //<<<<---- !00% leak according to Instruments 
[myVC release]; 

Je comprends le myVC est retenu par le contrôleur de navigation, donc je suppose que le contrôleur de navigation les libère lorsque la vue est sauté de la pile de navigation?

En outre, il y a une autre question délicate dans un de mes boucles, l'analyseur statique signale une fuite potentielle ici ...

//Walk through the scheduled alarms and create notifications 
NSMutableArray *fireDates = [[NSMutableArray alloc] init]; 
for(NSDate *fireDate in fireDates)   //<<<<---- Static analyzer is reporting potential leak here 
{ 
    UILocalNotification *localNotif = [[UILocalNotification alloc] init]; 
    if (localNotif == nil) 
    { 
     [fireDates release]; 
     return; 
    } 

    localNotif.fireDate = fireDate; 
    localNotif.timeZone = [NSTimeZone defaultTimeZone]; 

    localNotif.alertBody = [NSString stringWithFormat:@"%@", alarm.Label]; 
    localNotif.alertAction = NSLocalizedString(@"Launch", nil); 

    localNotif.soundName = UILocalNotificationDefaultSoundName; 

    localNotif.userInfo = infoDict; 
    localNotif.repeatInterval = NSWeekCalendarUnit; 

    [[UIApplication sharedApplication] scheduleLocalNotification:localNotif]; 
    [localNotif release]; 

} 
[fireDates release]; 

Ai-je besoin d'une certaine façon de libérer fireDate?

Merci d'avance pour votre aide!

Answer 1

Ces extraits sont tous les deux fins, comme les extraits. Sans voir votre code complet, il est impossible de dire si vous ne faites pas quelque chose d'idiot ailleurs. Avez-vous déjà publié votre navigationController (dans votre application, le délégué -dealloc, probablement)? C'est une fuite qui ne veut pas dire grand-chose, mais c'est peut-être ce qui déclenche le premier avertissement.

---

Modifier: en ce qui concerne le second extrait, le code semble bien (bien que le cas de retour de raccourci déranger certaines codeurs, qui préféreraient voir une déclaration break). L'analyseur statique peut être dérangé par l'absence d'un [localNotif release] (même si c'est évidemment inutile) dans le retour conditionnel.

Answer 2

Dans le premier extrait, qu'est-ce qui fuit? Les instruments vous indiqueront la ligne où elle a été affectée, qui n'est souvent pas la ligne «responsable» de la fuite (bien sûr, les numéros de ligne ont tendance à être désactivés car ils vous donnent l'adresse de retour et non l'adresse). Je suppose que c'est MyViewController qui fuit, et que les instruments se plaignent en fait de alloc (regardez dans le backtrace, cmd-E je pense).

Si vous cliquez sur la flèche à côté de l'adresse mémoire (vous devrez peut-être cliquer autour d'un bit et survoler l'adresse de fuite, je ne me souviens pas), vous verrez tous les alloc/retain/release/autorelease/malloc/free/CFRetain/CFRelease appelle cette adresse. Ignorez ceux avant alloc (ceux-ci sont pour un objet précédent qui est passé à vivre à la même adresse). La correspondance est conservée et les versions (automatiques). Vous pouvez faire correspondre une autorelease avec la version correspondante (retardée), car la libération différée se produira lorsque NSAutoreleasePool est libéré (ce qui est évident dans la trace de la pile). Recherchez une retenue sans relâchement (automatique) correspondant. C'est la fuite. Dans le second cas, il est utile que vous nous disiez ce que Clang SA vous dit (cliquez sur le petit triangle à gauche et il se développe pour vous montrer le flux de contrôle où la fuite se produit).

Mais je ne pense pas que la boucle fonctionne du tout, car fireDates est vide.