2017-01-03 1 views
3

Je reçois des plantages depuis le code de mise en page d'Apple pour un UICollectionViewFlowLayout et je n'ai aucune idée de la façon de les traiter (trace de pile ci-dessous). Toutes les suggestions seraient grandement appréciées.UICollectionViewData updateItemCounts Crash

Détails:

  • Malheureusement je ne peux pas reproduire le problème
  • La question n'est pas fréquent (il arrive en moins de 0,1% des séances), mais il est notre # 1 accident
#0. Crashed: com.apple.main-thread 
0 libsystem_platform.dylib  0x1879490d4 __bzero + 36 
1 UIKit       0x18e824e40 -[UICollectionViewData _updateItemCounts] + 544 
2 UIKit       0x18e824e40 -[UICollectionViewData _updateItemCounts] + 544 
3 UIKit       0x18e8e67e0 -[UICollectionViewData numberOfSections] + 28 
4 UIKit       0x18f086bc0 -[UICollectionViewFlowLayout _getSizingInfosWithExistingSizingDictionary:] + 612 
5 UIKit       0x18f088834 -[UICollectionViewFlowLayout _fetchItemsInfoForRect:] + 152 
6 UIKit       0x18e8e66b4 -[UICollectionViewFlowLayout prepareLayout] + 224 
7 UIKit       0x18e7cf574 -[UICollectionViewData _prepareToLoadData] + 164 
8 UIKit       0x18e7ceb5c -[UICollectionViewData validateLayoutInRect:] + 100 
9 UIKit       0x18e7ce55c -[UICollectionView layoutSubviews] + 212 
10 UIKit       0x18e76fa80 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1196 
11 QuartzCore      0x18bc1d9d8 -[CALayer layoutSublayers] + 148 
12 QuartzCore      0x18bc124cc CA::Layer::layout_if_needed(CA::Transaction*) + 292 
13 QuartzCore      0x18bc1238c CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 32 
14 QuartzCore      0x18bb8f3e0 CA::Context::commit_transaction(CA::Transaction*) + 252 
15 QuartzCore      0x18bbb6a68 CA::Transaction::commit() + 512 
16 QuartzCore      0x18bbb7488 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 120 
17 CoreFoundation     0x18886a0c0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32 
18 CoreFoundation     0x188867cf0 __CFRunLoopDoObservers + 372 
19 CoreFoundation     0x188868180 __CFRunLoopRun + 1024 
20 CoreFoundation     0x1887962b8 CFRunLoopRunSpecific + 444 
21 GraphicsServices    0x18a24a198 GSEventRunModal + 180 
22 UIKit       0x18e7dd7fc -[UIApplication _run] + 684 
23 UIKit       0x18e7d8534 UIApplicationMain + 208 
24 AppName Mobile     0x1000333e8 main (main.m:16) 
25 libdispatch.dylib    0x1877795b8 (Missing) 
+0

faites-vous un 'performBatchUpdates'? – SwiftArchitect

+0

@SwiftArchitect Je suis, est-ce que cela fournit un indice? – delrox

+0

Eh bien, il y avait http://stackoverflow.com/questions/28079393 et ​​http://stackoverflow.com/questions/37846653 et http://stackoverflow.com/questions/36334228 et http://stackoverflow.com/questions/25265183 et https://fangpenlin.com/posts/2016/04/29/uicollectionview-invalid-number-of-items-crash-issue, tous pendant 'performBatchUpdates' – SwiftArchitect

Répondre

1

Il existe un problème généralisé avec les nombres d'articles et performBatchUpdates. Plus précisément, vous pouvez rencontrer des divergences et un système d'exploitation s'affirment si ceux-ci ne sont pas synchronisés. Une affirmation n'est pas un accident.

Je ne pense que c'est ce que vous avez rencontré ici, et si oui, cette question peut-être un double de:


Assertion ou non, une approche défensive pour garder l'élément compte comme très bien décrit dans (†)UICollectionView invalid number of items crash problem and solution de blog de Lin Fang-Pen:

func updateItems(updates: [ItemUpdate]) { 
    collectionView.performBatchUpdates({ 
     for update in updates { 
      switch update { 
      case .Add(let index): 
       collectionView.insertItemsAtIndexPaths([NSIndexPath(forItem: index, inSection: 0)]) 
       itemCount += 1 
      case .Delete(let index): 
       collectionView.deleteItemsAtIndexPaths([NSIndexPath(forItem: index, inSection: 0)]) 
       itemCount -= 1 
      } 
     } 
    }, completion: nil) 
} 

Full Credit

0

Nous enfin a trouvé celle-ci. Ce n'était pas le problème performBatchUpdates signalé sur beaucoup d'autres cartes. La cause première était que nos sources de données renverraient un nombre négatif pour le nombre d'éléments. Le SDK utilise un int non signé, définissant ainsi un négatif retourné, et tenterait d'allouer des milliards de cellules (34 Go de mémoire virtuelle et de comptage). Il finirait par tomber en panne.