Problème de publication d'Objective-C sur iPhone

Question

J'ai un problème avec EX_BAD_ACCESS lorsque j'appelle la libération sur un objet NSStream dans mon dealloc sur l'iPhone.

Le code suivant

- (void)dealloc {
    DLog(@"dealloc started for: %@",self);
    @synchronized(self) {
        lookupCount--;
    if (lookupCount==0) {
        UIApplication* app = [UIApplication sharedApplication];
        app.networkActivityIndicatorVisible = NO;
        }
    }
    DLog(@"inStream retain count before release: %d",[inStream retainCount]);
    [inStream release];
    DLog(@"outStream retain count before release: %d",[outStream retainCount]);
    [outStream release];
    [queryToSend release];
    [resultString release];
    [data release];
    [super dealloc];
    NSLog(@"dealloc finsihed for : %@",self);
    }

se bloque avec EX_BAD_ACCESS sur le     [libération en aval]; ligne.

La sortie du journal est la suivante

2009-04-29 13:16:28.547 App[30580:20b] -[SimpleQuery dealloc] [Line 160] dealloc started for: <SimpleQuery: 0x56e540>
2009-04-29 13:16:28.547 App[30580:20b] -[SimpleQuery dealloc] [Line 168] inStream retain count before release: 1
2009-04-29 13:16:28.548 App[30580:20b] -[SimpleQuery dealloc] [Line 170] outStream retain count before release: 1

Vous vous demandez si quelqu'un a une idée de la raison pour laquelle cela pourrait être?

Answer 1

Dans un commentaire, vous avez dit ceci à propos de outstream

  

Il est créé par un appel à   getStreamsToHostNamed: port: inputStream: outputStream:   qui ne devrait pas retourner autoreleased   objets que je ne pense pas.

Il est en fait auto-publié. Sauf si vous conservez cet objet quelque part dans votre code, vous n'êtes pas responsable de la gestion de sa mémoire.

Vous devriez consulter le Consignes de gestion de la mémoire Apple .

  

De nombreuses classes fournissent des méthodes de   form + className ... que vous pouvez utiliser pour   obtenir une nouvelle instance de la classe.   Souvent appelé «commodité»   constructeurs ", ces méthodes créent un   nouvelle instance de la classe, initialiser   et le retourne pour que vous l’utilisiez.   Bien que vous puissiez penser que vous êtes   responsable de la libération d'objets   créé de cette manière, ce n'est pas   le cas selon la politique Cacao   set: le nom de la méthode ne contient pas   " alloc " ou "copier", ou commencer par   "nouveau". Parce que la classe crée le   nouvel objet, il est responsable de   disposer du nouvel objet.

Answer 2

Quelques problèmes potentiels:

• Vous êtes en train de vous verrouiller pour effectuer la boucle de décrémentation lookupCount, ce qui, je suppose, signifie que vous vous attendez à ce que ce code soit exécuté à partir de différents threads. Cela devrait être un drapeau rouge, car si vous désallouez une instance de deux threads simultanément, l’un de ces threads finira par essayer de désallouer une instance déjà désallouée.
• Le dernier appel NSLog essaiera d'imprimer self qui aurait déjà été désalloué.

Je sais que rien de tout cela ne concerne spécifiquement [version en sortie] , mais ils pourraient être liés. Vous pouvez essayer de déboguer ceci avec NSZombieEnabled pour obtenir plus d'informations.

Assurez-vous également que la publication de inStream ne libère pas implicitement outStream , etc.