"message envoyé à l'instance désaffectée 0xec75b0", mais 0xec75b0 ne devrait même pas être visible

Question

Je travaille sur une application iPhone qui effectue une communication avec le serveur à initialiser la première fois qu'il est exécuté. J'ai une classe ServerCommunication avec des méthodes pour chacune des tâches de base à exécuter (authentification d'un utilisateur, obtention d'une clé d'activation, téléchargement de mises à jour, etc.), et une nouvelle instance de ServerCommunication est créée pour chaque tâche; Je ne les réutilise pas, même si ce serait plus efficace.

Lorsque l'utilisateur termine le premier écran d'initialisation, ServerCommunication est créé quatre fois. Je le garde avec NSLog(@"Initializing ServerCommunication instance %p", self); dans sa méthode -init. Le deuxième écran d'initialisation appelle également ServerCommunication plusieurs fois lorsque l'utilisateur appuie sur le bouton "Suivant", mais sur sa dernière instanciation, l'application se bloque avec le message -[ServerCommunication insertDataIntoLocalDB:]: message sent to deallocated instance 0xec75b0 dans la console. La chose est, 0xec75b0 est l'adresse de la première instance de ServerCommunication que j'ai créé en arrière au premier écran. Pourquoi enverrait-il des messages à cette instance? Je ne les retiens nulle part; ils sont pour la plupart autoreleased. Si cela est utile, toutes les méthodes de cette classe effectuent un téléchargement asynchrone de données XML avec NSURLConnection, puis l'analysent avec NSXMLParser. La méthode de délégué de l'analyseur -(void)parserDidEndDocument:(NSXMLParser *)parser envoie ensuite des notations NSN qui sont reçues par des méthodes dans mes contrôleurs de vue afin qu'ils sachent si passer à l'écran suivant ou y rester et afficher un message d'erreur.

L'aide est très appréciée!

Answer 1

La première chose que je ferais est d'allumer NSZombies, qui devrait vous permettre de casser au point où votre zombie est envoyé.

Une cause fréquente de problèmes de ce type est lorsque vous avez des objets avec des références faibles les uns aux autres qui ne sont pas alloués et libérés en même temps. Donc (hypothétiquement), un autre objet stocke un pointeur vers votre objet ServerCommunication en tant que délégué ou propriétaire. Lorsque ServerCommunication est désalloué, il ne se désinscrit pas, et un peu plus tard, l'objet contenant la référence faible tente de vous envoyer un message.

Si je devais deviner complètement (et je le fais!), Je parie que vous ajoutez vos objets ServerCommunication en tant qu'observateur NSNotification, mais ne les supprimez jamais. Essayez de vous assurer que vous faites ceci:

[[NSNotificationCenter defaultCenter] removeObserver:self]; 

avant la désallocation. (Il est également possible qu'il y ait un chemin plus tortueux impliquant NSNotification ici - comme un pointeur vers l'objet ServerCommunication transmis comme données au contrôleur de vue, qui essaye alors de le signaler.)