2009-04-29 5 views
0

J'ai un problème que j'obtiens EX_BAD_ACCESS lors de l'appel de la libération sur un objet NSStream dans mon dealloc sur l'iPhone.Objective-C sur iPhone problème de publication

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); 
    } 

des collisions avec EX_BAD_ACCESS sur le [communiqué de outstream]; ligne.

sortie du journal se présente comme suit

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 des idées pour lesquelles cela pourrait être?

+0

Pouvez-vous publier comment créez-vous votre objet inStream? Il se peut que l'objet ait été auto-libéré par une autre méthode, et c'est pourquoi il échoue lorsque vous essayez de le libérer. – pgb

+0

Il est créé par un appel à getStreamsToHostNamed: port: inputStream: outputStream: qui ne devrait pas retourner les objets auto-libérés Je ne pense pas –

Répondre

1

Dans un commentaire, vous avez dit ceci à propos outstream

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

Il est en fait auto-libéré. À moins que vous ne conserviez cet objet quelque part dans votre code, vous n'êtes pas responsable de la gestion de la mémoire. Vous devriez jeter un oeil à la Apple Memory Management Guidelines.

De nombreuses classes fournissent des méthodes de la forme + className ... que vous pouvez utiliser pour obtenir une nouvelle instance de la classe. Souvent appelés «constructeurs de commodité», ces méthodes créent une nouvelle instance de la classe , l'initialisent et la renvoient à votre attention. Bien que vous pourriez penser que vous êtes responsable de la libération des objets créés de cette manière, ce n'est pas le cas selon la politique Cocoa set-le nom de méthode ne contient pas « alloc » ou « copier » ou commencer "nouveau". Parce que la classe crée le nouvel objet , il est responsable pour de disposer du nouvel objet.

+0

Merci. Cela ressemble beaucoup à mon incapacité à saisir la différence entre [self setStringVariable: aString]; self.stringVariable = aString; et stringVariable = aString; sur les variables retenues synthasées. –

0

Quelques problèmes potentiels:

  • Vous verrouillage sur l'auto pour faire la boucle de décrémentation lookupCount, que je suppose signifie que vous attendez ce code pour être exécuté à partir de différents threads. Cela devrait être un drapeau rouge, car si vous libérez une instance de deux threads simultanément, l'un de ces threads finira par essayer de libérer une instance déjà désallouée. L'appel NSLog final essayera d'imprimer self qui aurait déjà été désalloué.

Je ne connais aucun d'entre eux se rapporte spécifiquement à [outStream release], mais ils pourraient être apparentés. Vous pouvez essayer de déboguer ceci avec NSZombieEnabled pour obtenir plus d'informations.

Aussi, assurez-vous que la libération inStream ne libère implicitement outStream, etc.

Questions connexes