2010-07-19 5 views
0

donc sous-vue Instruments me dit que j'ai trois fuites de mémoire originaires de cette méthode (plus précisément, il souligne la ligne: [self.view addSubview: menuBar.view];fuite lors de l'ajout

Je ne vois pas Je garde une référence à l'objet menuBar et je le libère.Quelqu'un de plus intelligent que moi qui peut expliquer? Est-ce une coïncidence que j'ai trois éléments de menu dans mon XIB et je reçois trois fuites

Voici la méthode entière:

// vc racine appelle à activer l'affichage sta te de la barre de menu à l'écran

-(IBAction) showToolBar { 

//if no toolbar exists, create one and add it to the view 
if (!menuBarView) { 


MenuBarViewController *menuBar = [[MenuBarViewController alloc] initWithNibName:@"MenuBarViewController" bundle:nil]; 
    menuBar.book = self.selectedTitleDeck; 
    menuBar.booksArray = self.allTitleDeck; 
    self.menuBarView = menuBar; 
    [self.view addSubview:menuBar.view]; 
    [menuBar release]; 

} 

CGRect frame = menuBarView.view.frame; 

[UIView beginAnimations:nil context:NULL]; 


if (self.toolBarIsDisplayed == NO) { 
    //show the toolbar 
    frame.origin.y = 725; 
self.toolBarIsDisplayed = YES; 

} else if (self.toolBarIsDisplayed == YES) { 
    //hide the toolbar 
    frame.origin.y = 788; 
    self.toolBarIsDisplayed = NO; 
} 

self.menuBarView.view.frame = frame; 


[UIView commitAnimations]; 


} 
+0

En vérifiant que vous voyez cela sur un appareil et non sur le simulateur, n'est-ce pas? – Nick

+0

D'accord avec la question de Nick - est-ce sur un appareil ou un simulateur? Le simulateur est un non-non lors de la vérification des fuites. En passant, la dernière fois que j'ai vu une fuite dans addSubview: était dans une application multithread, où j'ai fait des appels d'interface utilisateur en dehors du thread principal. Votre application n'est pas multithread est-ce? – Kalle

+0

J'ai essayé de trouver cette fuite pendant des jours. Et oui, je le faisais en simulateur. Commuté sur l'appareil, pas de fuite à trouver. Sentez-vous assez stupide, mais, vivez et apprenez, je suppose. Merci les gars! – isaac

Répondre

0

Comme suggéré dans les commentaires à ma question, le problème n'était pas dans le code, mais dans l'exécution de mon application dans le simulateur et en essayant de détecter les fuites de mémoire.

Lorsque Instruments est exécuté par rapport au code sur le périphérique, aucune fuite n'est signalée. Mon prix de consolation est une compréhension beaucoup plus profonde de la gestion de la mémoire mis au jour en deux jours d'essayer de localiser une fuite qui n'existait pas.

Merci à tous pour vos conseils, très appréciés.

1

addSubview: conserve la vue passée dans (voir la reference). Une fois que vous appelez addSubview, vous pouvez libérer ce point de vue, comme:

MenuBarViewController *menuBar = [[MenuBarViewController alloc] initWithNibName:@"MenuBarViewController" bundle:nil]; 
    menuBar.book = self.selectedTitleDeck; 
    menuBar.booksArray = self.allTitleDeck; 
    self.menuBarView = menuBar; 
    [self.view addSubview:menuBar.view]; 
    [menuBar.view release]; 
    [menuBar release]; 
} 
+0

-1 vous ne pouvez pas faire cela. Vous violeriez les règles de gestion de la mémoire puisque vous n'avez pas obtenu menuBar.view par new, alloc ou copy et vous ne l'avez pas conservé. – JeremyP

+0

Il est toujours conservé par addSubview. Il s'agit probablement d'un objet autoreleased, donc il restera collé jusqu'à ce qu'il soit conservé par addSubview. Vous laissez entendre que vous ne pouvez jamais conserver des objets non obtenus par init ou de nouvelles méthodes, ce qui est faux. – jergason

0

Montrez-nous ce qui se passe dans la méthode dealloc de MenuBarViewController. Je soupçonne que vous oubliez de libérer ses variables d'instance.