EXC_BAD_ACCESS NSArray de ManagedObjects (Données de base)

Question

Quelque chose d'étrange se passe avec mon application iPhone. J'utilise Core Data pour stocker des données dans une base de données SQLite. La première fois que mon application démarre, j'essaie de lire une table pour retourner toutes les lignes pour remplir un UITableView avec une liste de choses pour l'utilisateur à sélectionner. S'ils ont choisi le premier élément de la liste, j'obtiens une exception EXC_BAD_ACCESS. S'ils choisissent un autre élément, tout semble OK. Voici l'exemple de code: Sport et Team sont NSManagedObjects. sports est un objet NSArray of Sport récupéré à l'aide d'un NSFetchedResultsController (fetchedObjects). Je peux afficher la liste des objets fins dans le UITableView (j'utilise le même tableau pour l'appel cellForRowAtIndexPath() sans aucun problème

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath { 
    Sport *sport = (Sport *)[sports objectAtIndex:indexPath.row]; 

    if (teamSetup) { 
     if (team.sport != sport) { 
      [team setSport:sport]; <-- this is where the EXC_BAD_ACCESS happens 

      NSError *error; 
      [team.managedObjectContext save:&error]; 
     } 
     [self.navigationController popViewControllerAnimated:YES]; 

    } else { 
     // .. do some other stuff 

    } 
    [tableView deselectRowAtIndexPath:indexPath animated:YES]; 
} 

MISE À JOUR: Il semble affecter seulement le dernier enregistrement du NSArray au lieu de la première Après avoir redémarré l'application, le problème disparaît et le code fonctionne comme prévu: (

Answer 1

Il n'y a rien de mal à la ligne ci-dessus où se produit EXC_BAD_ACCESS. Cependant, il pourrait offrir un indice qu'il y a un problème avec les objets team ou sport La première piste à suivre est que l'un de ces objets a été désalloué car il n'a pas été suffisamment soutenu.

Les objets libérés peuvent ne pas être libérés immédiatement. C'est pourquoi le EXC_BAD_ACCESS peut se produire à des heures étranges. Les objets ne sont libérés que lorsque le fragment de mémoire qu'ils utilisaient n'est plus nécessaire. D'autres objets utiliseraient bien entendu le même morceau. Donc, quand ce morceau devient éligible pour la désallocation est hors de votre contrôle en tant que développeur. C'est géré par le runtime.

La meilleure chose à faire est d'exécuter d'abord l'analyseur, puis d'exécuter Instruments, profilant avec l'instrument Leaks.

Il y a une grande explication de tout cela, et point par point des conseils sur les traquer EXC_BAD_ACCESS erreurs sur le site de Lou Franco:

Understanding EXC_BAD_ACCESS