Existe-t-il un bogue dans NSOperation sous Mac OS X 10.6?

Question

Si je libère une instance de NSOperation avant de lui envoyer -init, j'obtiens un segmentation fault.

raisons je pense que ce code est valide:

• Apple fait cela dans its documentation.
• Gnustep le fait dans son implementation of NSNumber, donc il est assez certain que c'est aussi dans le code d'Apple. (Au moins était.)
• NSObject s -init ne fait rien, donc -release, qui appartient à NSObject devrait fonctionner avant cela.

// gcc -o test -L/System/Library/Frameworks -framework Foundation test.m 

#import <Foundation/Foundation.h> 

int main(int argc, char *argv[]) { 
    NSOperation *theOperation = [NSOperation alloc]; 
    [theOperation release]; 
} 

• Que pensez-vous, est-ce un bug?
• Pouvez-vous me montrer un exemple d'une autre classe qui a le même comportement?
• Une idée de pourquoi cela se passe-t-il?

Answer 1

Envoi de message autre que init à un objet qui n'a pas été initialisé est valide pas le code AFAIK. Appelez l'initialiseur de la superclasse, puis relâchez et je parie que ça ne va pas planter (bien que l'initialisation d'une classe retourne une classe complètement indépendante qui me frappe comme doubleplusungood).

Answer 2

Il n'y a rien de valide à propos de ce code.

Ressaisissez votre -init comme:

- (id) init 
{ 
    if (self = [super init]) { 
     [self release]; 

     NSNumber *number = [[NSNumber alloc] initWithInteger:6]; 
     return number; 
    } 
    return self; 
} 

Bien sûr, le code est encore un non-sens, mais il ne tombe pas en panne.

Vous devez toujours appeler par au initialiseur de super avant la messagerie auto. Et vous devez toujours le faire avec le motif ci-dessus.

Answer 3

Je pensais que vous devez initialiser votre superclasse avant d'appeler la version, mais selon this example dans les documents d'Apple ce n'est pas le cas.

Donc ce peut être un bug, mais certainement pas important.

Answer 4

Mon analyse précédente n'était pas vraiment correcte.

Cependant, je tiens à souligner que ce problème peut se produire avec des classes différentes. Cela dépend en fait de la classe que vous sous-classez. Subclassing NSObject a pas de problème, mais le sous-classement NSOperation, NSOperationQueue et NSThread est un problème, par exemple.

Et cela se produit parce que tout comme vous pourriez faire, les classes que vous sous-classe peut affecter des choses dans leur méthode -init. Et c'est aussi là que vous définissez à nil les variables que vous ne l'avez pas encore attribués (et peut-être faire plus tard dans votre code). Ainsi, en appelant le -release sur vous-même sans le précédent -init, vous pourriez provoquer la libération par l'une de vos classes parentes de l'objet qu'elle n'avait pas alloué.Et ils ne peuvent pas vérifier si leur objet est nil, car il n'a même pas eu l'occasion d'initier chaque objet/valeur dont il a besoin.

Cela pourrait aussi être la raison pour laquelle libérer NSOperation sans init a fonctionné sur 10.5 et ne fonctionne pas sur 10.6. L'implémentation 10.6 a été réécrite pour utiliser des blocs et Grand Central Dispatch, et donc, leurs méthodes init et dealloc ont pu changer considérablement, créant un comportement différent sur ce morceau de code.