EXC_BAD_ACCESS lors du déplacement de l'application iPhone du simulateur 2.2 à 3.0

Question

Eh bien, j’avais une application que je développais dans le SDK iPhone 2.2 et que j’ai récemment construite et lancée dans le simulateur 3.0. Le SDK de base est toujours défini sur 2.2. Je pensais que cela éviterait les problèmes. Au lieu de cela, je reçois

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000a1b1c1f3
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                 0x92f4b688 objc_msgSend + 24
1   Foundation                      0x305085bd -[NSCFString isEqualToString:] + 61
2   HappyApp                        0x00002c27 -[CombinationsTableViewController loadData] + 220 (CombinationsTableViewController.m:64)

Le blocage se produit sur une ligne très simple, où total est un UITextField

if (![total.text isEqualToString:@""] ) {

Quelqu'un at-il rencontré cela? J'ai l'impression que c'est un problème de conflit de fil, ou que toute mon application ne compile pas correctement. Cela fonctionne dans le simulateur 2.2.1. Si cela ne s'avère pas être le moyen de tester une application 2.2 dans OS 3.0, que dois-je faire d'autre que de changer de liste déroulante?

Mise à jour : Andrew Pouliot avait raison de dire qu'il s'agissait d'un problème de référence publié. Le débogueur pointait une ligne alors je me suis trompé d'indices. Le coupable était en fait cette première ligne:

if(!([total.text isEqual:totalTextCache]
  && [divisions.text isEqual:divisionsTextCache])) {
  //Loads the data for the table only if the values were actually changed
  totalTextCache = total.text; //ditto for divisions
}

Ces lignes sont les seules utilisations de totalTextCache et sont devenues invalides si total.text était modifié. Cela n'a jamais posé de problème dans la version 2.2.1 probablement parce que l'ancien total.text n'a jamais été publié par le moteur d'exécution lorsqu'il a changé de valeur. Mais ce code était faux. Je l'ai corrigé en le changeant pour qu'il fasse exactement ce que je pensais que faisaitEqual:

if(!(total.text==totalTextCache && divisions.text==divisionsTextCache))

Parce que je ne voulais pas vraiment copier les NSString , mais juste vérifier si elles avaient changé (et donc la référence aurait changé, cela fonctionne. Le code incorrect a bien fonctionné dans le 2.2.1 runtime car l'ancienne référence pouvait toujours avoir sa propriété de hachage vérifiée et comparée par isEqual .

Answer 1

Lorsque j'ai installé mon SDK 3.0, mes outils 2.0 ont disparu, donc je ne suis pas sûr que cela soit applicable, mais je ne pense pas que les versions de simulateur soient conçues pour être compatibles binaires avec les environnements d'exécution futurs.

Il est cependant probable que le problème réside dans votre code. Si tel est le cas, je peux affirmer que vous avez un problème de gestion de la mémoire et non un "conflit de thread". Tout se passe sur le thread principal dans UIKit (pas thread safe).

Vérifiez où vous avez configuré votre variable totale; il a probablement déjà été publié au moment où vous utilisez cette méthode. Assurez-vous que votre retention est raisonnable.

Avez-vous la même erreur lorsque vous compilez pour la version 3.0?