EXEC_BAD_ACCESS lors de la suppression de ModalViewController

Question

J'utilise une recette standard pour présenter ModalViewControllers dans mes applications iPhone, mais j'ai rencontré une situation où la recette est cassée et je suis confus. Voilà comment je (à peu près toujours) mis en place la présentation:

MatcherViewController *controller = [[MatcherViewController alloc] initWithNibName:@"MatcherView" bundle:nil]; 
[controller setModalTransitionStyle:UIModalTransitionStyleCoverVertical]; 
[controller setDelegate:self]; 
[self presentModalViewController:controller animated:YES]; 
[controller release]; 

Cela fonctionne toujours bien jusqu'à ce que j'ai ajouté une chose au mélange, et j'ai envoyé un message au nouvel objet de commande avant je l'ai présenté, comme si:

MatcherViewController *controller = [[MatcherViewController alloc] initWithNibName:@"MatcherView" bundle:nil]; 

[controller setPrimary:primaryIndex andSecondary:secondaryIndex]; 

[controller setModalTransitionStyle:UIModalTransitionStyleCoverVertical]; 
[controller setDelegate:self]; 
[self presentModalViewController:controller animated:YES]; 
[controller release]; 

Ajout cet appel de méthode semble fonctionner jusqu'à ce que je rejette le contrôleur de vue ... à quel point les application se bloque avec un signal EXEC_BAD_ACCESS. Je peux le faire fonctionner avec la ligne supplémentaire si j'enlève [controller release], mais j'ai peur que cela cause une fuite. Des idées pourquoi envoyer un message à l'objet avant la présentation provoquerait cela? Existe-t-il un meilleur moyen de transmettre des paramètres simples au ModalViewController?

Merci pour votre temps à redresser les débutants, p

Answer 1

Je vais deviner que primaryIndex et secondaryIndex sont objets mal conservés tels qu'ils dépendent de la vue modale les retenir pour survivre. Lorsque vous relâchez la vue modale, ils meurent mais sont ensuite appelés ailleurs dans le code provoquant le crash.

Si elles sont des propriétés conservées de la classe, accédez-y toujours avec la construction "self.propertyName" pour vous assurer que leur nombre de retenues est correctement géré. D'après mon expérience, l'optimisation prématurée sous la forme d'un relargage excessif est aujourd'hui une cause majeure de céphalées d'Objective-C.

Les codeurs Objective-C de la vieille école étaient paranoïaques à propos des fuites car il leur était presque impossible de les retrouver à la main dans la journée. C'est pourquoi beaucoup de ressources mettent encore beaucoup d'emphase sur la prévention des fuites au fur et à mesure. Cependant, avec les outils d'analyse modernes, les fuites sont généralement triviales à traquer.

Lors du développement initial, en cas de doute, ne pas libérer.

Answer 2

Dans vos contrôleurs méthode dealloc, assurez-vous que vous n'êtes pas sur quoi que ce soit libérer.