Memory Leak NSMutableArray
Salut, c'est encoire moi :kicking:
Alala la gestion de la mémoire, quelle belle invention ;D
Grâce au logiciel CLANG GUI j'ai pu identifier les trois quarts de mes problèmes que me signalait l'instrument memory leak du SDK.
J'avoue que j'ai pas encore tout compris sur les nonatomic et retain, mais j'ai pigé le 1 alloc = 1 release.
Cependant j'ai encore besoin de vos lumières :why?: (qui a dit assisté ? :fouf):)
Dans mon code si dessous :
Je construit mon objet Message et hop je le met dans le tableau... C'est tout beau sauf que instruments me dit que mon objet Message n'est jamais release.
Dans le détails j'ai bien :
malloc 16 [[Message alloc] initWithDatabaseRow:statement];
retain 0 [tab addObject:message];
release 0 [message release];
Mais que je mette release ou pas, j'ai une fuite de mémoire.
Alala la gestion de la mémoire, quelle belle invention ;D
Grâce au logiciel CLANG GUI j'ai pu identifier les trois quarts de mes problèmes que me signalait l'instrument memory leak du SDK.
J'avoue que j'ai pas encore tout compris sur les nonatomic et retain, mais j'ai pigé le 1 alloc = 1 release.
Cependant j'ai encore besoin de vos lumières :why?: (qui a dit assisté ? :fouf):)
Dans mon code si dessous :
<br />Message *message = nil;<br />while(...) {<br /> <br />message = [[Message alloc] initWithDatabaseRow:statement];<br />[tab addObject:message];<br />[message release];<br /> <br />}<br />
Je construit mon objet Message et hop je le met dans le tableau... C'est tout beau sauf que instruments me dit que mon objet Message n'est jamais release.
Dans le détails j'ai bien :
malloc 16 [[Message alloc] initWithDatabaseRow:statement];
retain 0 [tab addObject:message];
release 0 [message release];
Mais que je mette release ou pas, j'ai une fuite de mémoire.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et là ?
message sera releasé, et donc désalloué, lorsque la NSMutableArray tab le sera. En effet une NSMutableArray effectue un retain sur les objets qui lui sont ajoutés, et un release lorsqu'elle est désallouée.
Je pense donc que la fuite mémoire vient de tab, pas de message.
Je croyais que :
faisait aussi un retain count à 1, contrairement à :
La fuite ne vient-elle pas de là ?
Et à quoi cela sert dans son cas ? (juste pour info)
On voit souvent cette habitude de mettre à nil les variables lors de leur déclaration. J'ai l'impression que c'est une mode. Cela peut servir pour des tests ultérieurs : if(message)
Par exemple avec
Message * message=nil;
while(message==nil) {
.....
if( ....) {
message=
}
}
Exécution
Par ailleurs NSLog(@%@",[string class]); provoque un crash de l'appli ...
Merci pour l'info. Son bug doit donc bien venir de tab.
Et que contient la variable message à la création quand elle n'est pas initialisée par nil ?
N'importe quoi. En gros ce qui était sur la pile d'exécution à l'endroit ou la variable locale a été placée.
J'ai encore des lacunes sur la gestions de la mémoire Même quand par exemple je fais :
ou
J'ai une fuite de mémoire. Et si j'essai un autorelease l'appli crash.
En ce qui concerne mon poste initiale, il semble bien que le problème vienne du NSMutableArray que je release jamais et donc lui et les objets qui contient ne sont jamais libéré.
Ce tableau me sert dans un TBVController, je fais [self.data = [DBEngine createList]] sur un viewDiDAppear.
Du coup je peux pas faire un [self.data release]; et je sais pas trop comment m'y prendre autrement :crackboom:-
Il ne faut évidemment pas faire de release ni d'autorelease sur les objets retournés par dateWith... et stringWith..., puisque, comme leur nom ne commencent ni par init ni par copy ou mutableCopy, tu n'es pas propriétaire de l'objet (et par conséquent, ces méthodes ont DEJA fait un autorelease).
Par contre, il faut évidemment faire un [date release] et un [text release] dans la méthode dealloc de la classe, sous peine de leaker un NSDate et un NSStringÂ
Il faut regarder dans la doc si sqlite3_column_text() ne renvoie pas une chaà®ne allouée par malloc(), auquel cas il faut faire un free. A voir
On peut libérer les éléments du tableau sans le détruire
[...... removeAllObjects]
Dès lors les objets ainsi détachés de la collection recevront un message release et seront détruits si leur retain count est à 1.
Réponse négative : The pointers returned are valid until a type conversion occurs as described above, or until sqlite3_step() or sqlite3_reset() or sqlite3_finalize() is called. The memory space used to hold strings and BLOBs is freed automatically
En fait avoir un pic rouge sous Instruments pour le leaks n'est pas rédibitoire ? Les leaks de mes NSString ou NSDate alloué (16 bytes) avec stringWith... dateWith... sont bien indiqué comme autorealese sauf qu'on ne retrouve pas (-16 bytes). Mais à partir du moment ou on vois bien qu'ils ont reçu l'instruction release, on peut rien faire de plus ?
Idem j'ai des tableaux que j'init dans le viewDiDload et que je release dans le dealloc. J'ai des leak également pour ces tableaux où l'on voit 32 bytes à la ligne de l'alloc et toujours 0 quand il passe dans le dealloc (au lieu de -32 je suppose)
Dois je supposer que pour les leaks indiqué, si on voit bien qu'on a une instruction release sur l'objet, on y peut rien ?
Non, il faut faire disparaà®tre les pics.
Pareil, avec une appli clean, il n'y a aucun pic dans l'instrument Leaks
Ce post parle de la même chose