2011-01-20 4 views
2

Salut, j'ai le code suivantlibération NSInvocationOperation provoque l'application crash

NSString *analyticsStr = [[NSString alloc] initWithString:[self constructXMLMessage:TagObj]]; 
NSInvocationOperation *operation = [[NSInvocationOperation alloc] initWithTarget:self 
                     selector:@selector(sendAnalyticsString:) 
                      object:analyticsStr]; 
[operationQueue addOperation:operation]; 
[analyticsStr release]; 
//[operation release]; 

quand je décommenter [Libération cde] plantage de mon application. Et je reçois cette erreur:

malloc: * erreur pour objet 0x726ed50: pointeur étant libéré n'a pas été alloué * mis un point d'arrêt dans malloc_error_break pour déboguer

Je suis d'avis que NSOperationQueue prend soin des objets de retenue. Y at-il quelque chose que je fais mal ou pas conscient de.

+2

Il conservera votre opération, donc vous avez un autre problème. Que faites-vous avec l'objet quand il se termine? N'importe quoi? –

+0

oui vous avez raison, il y a probablement un autre problème où .... –

Répondre

3

Utilisez le modèle Zombies d'Instruments pour le déboguer. Un indicateur apparaîtra dans le scénario lorsque vous envoyez un objet à un message après qu'il aurait dû être libéré; vous pouvez cliquer sur le bouton de ce drapeau pour commencer à rechercher ce qui a indûment libéré l'objet. À propos, vous n'avez pas besoin de créer cet objet chaîne. La chaîne renvoyée par constructXMLMessage: durera aussi longtemps que le pool autorelease actuel, ce qui devrait être tout le temps nécessaire pour travailler avec. Il ne mourra pas soudainement sur toi.

+0

re: "La chaîne que' constructXMLMessage: 'retourne durera aussi longtemps que le pool autorelease actuel, ce qui devrait être tout le temps dont vous avez besoin pour travailler avec lui "- vous voulez dire que ça va durer assez longtemps pour passer à NSInvocationOperation, qui le retiendrait alors, n'est-ce pas? Même si l'opération utilise une version conservée, le pool d'autorelease (actuel) peut être parti au moment de l'exécution de l'opération. – Richard

+0

Bon point; J'avais raté ça. Oui, les docs pour NSInvocationOperation indiquent que l'initialiseur désigné indique à l'invocation de conserver ses arguments, de sorte que la chaîne doit être sûre même après que le pool se soit écoulé, jusqu'à ce que l'opération soit terminée. –

Questions connexes