0

EDIT: we have found that this does NOT happen if we use a UICollectionView that was created by Interface Builder. Clearly they are doing something we are not during instantiation. here is our routine up:

UICollectionViewFlowLayout* layout = [UICollectionViewFlowLayout alloc];
[layout setScrollDirection:UICollectionViewScrollDirectionVertical];
colView = [[UICollectionView alloc] initWithFrame:f collectionViewLayout:layout];
[colView setBackgroundColor:[UIColor blackColor]];
[colView setDataSource:self];
[colView setDelegate:self];
[colView setCanCancelContentTouches:NO];
[colView setClipsToBounds:NO];
[colView registerNib:[UINib nibWithNibName:@"CTTextViewCell" bundle:nil] forCellWithReuseIdentifier:@"LabelCell"];
[self.view colView];

What are we missing for proper delete / insert to work?

================

We are seeing a very strange memory issue using a UICollectionView that has been programmatically generated (though I doubt that matters). If we call any of these:

reloadItemsAtIndexPaths:
deleteItemsAtIndexPaths: 
insertItemsAtIndexPaths:

The system gets into an infinite loop and churns up memory until it crashes.

Strangely, calling reloadData does not cause this issue. Pausing the execution shows the following, with various calls above this stack based on when you press pause. 

4   0x32423d86 in -[UICollectionView _endItemAnimations] () 
5   0x000bc174 in -[ASCollectionViewController collectionView:didSelectItemAtIndexPath:] at /Users/rwitman/Documents/git/airshow/photoChuck/Source/ASCollectionViewController.m:248 
6   0x3247ea96 in -[UICollectionView _userSelectItemAtIndexPath:] () 
7   0x3247e7bc in -[UICollectionView touchesEnded:withEvent:] () 
8   0x323e88da in forwardTouchMethod () 
9   0x323e88da in forwardTouchMethod () 
10  0x32259380 in _UIGestureRecognizerUpdate () 
11  0x322911b4 in -[UIWindow _sendGesturesForEvent:] () 
12  0x32290b62 in -[UIWindow sendEvent:] () 
13  0x32265f58 in -[UIApplication sendEvent:] () 
14  0x32264746 in _UIApplicationHandleEventQueue () 
15  0x2faa6f26 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () 
16  0x2faa63ee in __CFRunLoopDoSources0 () 
17  0x2faa4bde in __CFRunLoopRun () 
18  0x2fa0f540 in CFRunLoopRunSpecific () 
19  0x2fa0f322 in CFRunLoopRunInMode () 
20  0x347462ea in GSEventRunModal () 
21  0x322c61e4 in UIApplicationMain ()

Top calls can be: 

0   0x2fa20a2e in -[__NSFastEnumerationEnumerator nextObject] () 
0   0x2fa1ac76 in -[__NSDictionaryM countByEnumeratingWithState:objects:count:] () 
0   0x39de1898 in objc_object::sidetable_retain() () 
0   0x3a3acd2a in tiny_malloc_from_free_list ()

Any thoughts on what is going on?

ADDITIONAL One example is this rather inocuos code to remove an element from the collection view

// remove our asset from the local array that provides the data source for the collection view
[elementArray removeObjectAtIndex:index];

// now delete it visually
[colView deleteItemsAtIndexPaths:[NSArray arrayWithObjects:[NSIndexPath indexPathForItem:index inSection:0], nil]];

I also placed break points in the various dataSource delegates to see if they were being called repeatedly, but they are not. I couldn't get the code to stop via breakpoints, only pausing it, which left me in non-symbolication land.

MobileVet
  • 2,958
  • 2
  • 26
  • 42
  • Can you elaborate on "if we call several important class methods, the system gets into an infinite loop and churns up memory until it crashes"? Thats pretty vague. Also, there are confirmed reports of [reuse issues](http://stackoverflow.com/questions/19276509/uicollectionview-do-not-reuse-cells) in iOS7 simulator. – Timothy Moose Oct 11 '13 at 02:13
  • Timothy, the calls that produce this behavior are reloadItemsAtIndexPaths: deleteItemsAtIndexPaths: insertItemsAtIndexPaths: – MobileVet Oct 11 '13 at 02:46
  • we see the behavior on the device as well – MobileVet Oct 11 '13 at 02:53
  • Normally with infinite loops there's an obvious cycle. Can you identify the cycle? – Timothy Moose Oct 11 '13 at 03:19
  • Wish I could. I place break points everywhere, but none are hit. It stays in Apple's code. By the pause points it appears it is enumerating through some list, but I can't figure out what that could be. We have very few elements in the actual view. – MobileVet Oct 11 '13 at 03:36
  • Huh. Well, if you run out of ideas, you might try using [TLIndexPathTools](http://tlindexpathtools.com) in your view controller and letting it handle the batch updates for you. I'm using it on many table and collection views and haven't had any issues like this. – Timothy Moose Oct 11 '13 at 03:48
  • Thanks for the tip... frustrating. It must be something simple, but it sure would be nice to get a crash or error with a root cause. – MobileVet Oct 11 '13 at 04:06

0 Answers0