2009-03-26 6 views
3

Je constate un blocage intermittent sur [version de l'analyseur]. Je dirais que je le vois environ 5% du temps, et les données que j'analyse varient entre chaque crash. Je ne peux pas pour la vie de moi comprendre pourquoi.Le blocage EXC_BAD_ACCESS lors de la libération de NSXMLParser

Avant de soumettre un rapport de bogue à Apple (qui, avec ma chance, ne sera pas reproductible dans l'exemple de code), quelqu'un a-t-il déjà rencontré ce problème et sait-il ce qui se passe?

NSData *d = [data copy]; // data is typically 2K-13K bytes 
    @synchronized (xmlParserLock) { 
     [[NSURLCache sharedURLCache] setMemoryCapacity:0]; 
     [[NSURLCache sharedURLCache] setDiskCapacity:0]; 

     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
     NSXMLParser *parser = [[NSXMLParser alloc] initWithData:d]; 
     [parser setDelegate:self]; 
     [parser setShouldProcessNamespaces:NO]; 
     [parser setShouldReportNamespacePrefixes:NO]; 
     [parser setShouldResolveExternalEntities:NO]; 
     [parser parse]; 
     [parser release]; 
     [pool release]; 
    } 
    [d release]; 

Et voici le gdb 'où' la production, qui pointe vers [version de l'analyseur]:

#0 0x93d08d12 in xmlCharEncCloseFunc() 
#1 0x93cfc0e3 in xmlFreeParserInputBuffer() 
#2 0x93cfc08f in xmlFreeInputStream() 
#3 0x93cfbdac in xmlFreeParserCtxt() 
#4 0x961384d6 in -[NSXMLParser dealloc]() 
#5 0x00149de7 in -[MyParserClass parseResponse] (self=0x104e9f0, _cmd=0x1766dc) at /Users/mike/Documents/MyApp/Classes/MyParserClass.m:60 

Merci d'avance pour toute aide!

+0

est le fragment de méthode que vous montrer ici MyParserClass, et est la ligne [version de l'analyseur] 60? –

+0

Brent: C'est correct. –

Répondre

4

Je pense que j'ai tout compris - un code ailleurs dans l'application utilise les fonctions XML telles que:

xmlCtxtReadMemory() 
xmlClearParserCtxt(); 
xmlFreeParserCtxt(); 
xmlCleanupParser(); 
xmlFreeDoc(); 

Ces fonctions exécutent probablement dans un autre thread en même temps j'exécute le fragment de code que j'ai posté . NSXMLParser utilise évidemment les mêmes fonctions sous le capot.

J'ai ajouté un bloc synchronisé à l'autre code en utilisant le même objet de verrouillage que celui que j'utilise pour mon utilisation de NSXMLParser, et les plantages semblent avoir disparu. Donc, je suppose que la leçon ici est que ces fonctions XML ne sont pas totalement sûres pour les threads - à utiliser avec prudence!

0

Il semble que vous utilisiez plusieurs threads. Il pourrait y avoir un problème avec ça. Les bogues de filetage se présentent souvent sporadiquement. Vous pourriez également avoir un bug dans vos méthodes de délégué d'analyseur, que vous n'avez pas postées ici.

+0

J'ai lu que NSXMLParser ne fonctionne pas bien avec plusieurs threads, donc oui, j'ai synchronisé autour de son allocation et désallocation. En ce qui concerne le NSXMLParser, cela devrait supprimer l'angle de plusieurs threads du problème, je pense. –

+0

En ce qui concerne les méthodes déléguées, je ne vois tout simplement pas ce que je pourrais faire là-dedans, ce qui me permettrait de savoir pourquoi un mauvais accès se produit lors de la libération du NSXMLParser. C'est plutôt étrange. Merci pour vos commentaires. –

0

Vous devez supprimer vos données uniquement lorsque l'analyse est terminée. Dans la méthode déléguée appelée parserDidEndDocument: release data.

Espérons cette aide.

thierry

0

Vous devez supprimer uniquement vos données lors de l'analyse est terminée. Dans la méthode déléguée appelée parserDidEndDocument: release data.

Espérons cette aide.

thierry

Questions connexes