Pourquoi Assertion échec dans -[UISectionRowData refreshWithSection:tableView:tableViewRowData:]?

Question

 Échec de l'assertion dans -[UISectionRowData refreshWithSection:tableView:tableViewRowData:], /SourceCache/UIKit/UIKit-2380.17/UITableViewRowData.m:400

 *** Application terminée en raison d'une exception non capturée 'NSInternalInconsistencyException', raison : 'Échec d'allouer des magasins de données pour 997008923 lignes dans la section 0. Considérez l'utilisation de moins de lignes'

mon code

 -(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
  {

   return 1;

  }

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

{

   return [appDelegate.purchaseArray count];

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:  (NSIndexPath *)indexPath
   {
    static NSString *CellIdentifier = @"cell";

    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault         reuseIdentifier:CellIdentifier];
    }
    return cell;
}    

-(void)viewWillAppear:(BOOL)animated
{

    [cartTbl reloadData];

}

je n'ai pas compris quel est le problème dans cela?

Answer 1

Vérifiez votre tableView:heightForRowAtIndexPath:. Peut-être que vous retournez quelque chose comme NaN/+inf/-inf au lieu de la hauteur. C'était mon bug.

Rappelez-vous qu'il ne s'agit pas d'un crash pour les types double et float de diviser par zéro:

double d = 5.0;
double r = d/0.0;

Donc ceci peut vous aider:

if (isnan(r) || isinf(r)) {
    // ...
}

Answer 2

J'ai aussi eu un échec dans -[UISectionRowData refreshWithSection:tableView:tableViewRowData:]. Dans mon cas, cela a été causé par un estimatedRowHeight trop petit alors que j'utilisais :

func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
    return UITableViewAutomaticDimension
}

pour redimensionner automatiquement les cellules de la tableView. En définissant estimatedRowHeight à 2.0 au lieu de 1.0, le problème a été résolu.

Answer 3

J'ai eu une erreur comme celle-ci pour une raison différente. Mon application fonctionnait bien, quand j'ai décidé de changer quelque chose dans mon modèle de vue (l'objet auquel j'associais ma table). J'ai supprimé une propriété et recompilé. Soudain, l'application a lancé cette erreur.

Il s'est avéré qu'il y avait toujours une référence à la propriété supprimée dans le code que le compilateur n'avait pas repéré. J'avais nettoyé et reconstruit plusieurs fois, et le compilateur n'a jamais détecté cette erreur que j'avais manquée.

Redémarrer xcode a provoqué l'échec de la construction, avec la ligne incriminée maintenant mise en évidence comme une erreur. Une fois que j'ai corrigé cela, tout était à nouveau en ordre.

Si vous rencontrez des erreurs d'accès mémoire comme celle-ci et que vous voyez des choses étranges dans le débogueur, comme des propriétés avec des valeurs qui devraient être assignées à d'autres propriétés, alors vous pourriez avoir une erreur qui aurait dû empêcher votre construction de compiler que xcode n'a tout simplement pas repérée d'une manière ou d'une autre. Un redémarrage pourrait le corriger - ça vaut la peine d'essayer.

Answer 4

return [appDelegate.purchaseArray count]; semble être une valeur de déchets. Assurez-vous qu'elle soit initialisée.