Crash when Fetched Results Controller updates table after saving a background MOC - ios

I have a tableView hooked up to a FRC (Fetched Results Controller) , I also have two contexts , namely backgroundContext initialised in a private queue and a mainContext initialised on the main queue. I also have setup the didSaveNotification to pass the objects from one context to another. When ever i save some data in the backgroundContext it saves successfully and FRC updates ,but if i repeat the process again the app crashes with an error
'The left hand side for an ALL or ANY operator must be either an
NSArray or an NSSet.'
The saving is done through a form which is presented modally. The same viewController works fine if presented in other viewControllers . but crashes only in one particular one. But again other that presenting the Form no other extra stuff is being done.
Here's my entire crash report.
Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: 'The left hand side for an ALL
or ANY operator must be either an NSArray or an NSSet.'
* First throw call stack: ( 0 CoreFoundation 0x0000000103575495 exceptionPreprocess + 165 1 libobjc.A.dylib
0x0000000102fbb99e objc_exception_throw + 43 2 Foundation
0x00000001003c706b -[NSPredicateOperator
performOperationUsingObject:andObject:] + 826 3 Foundation
0x00000001003c6c1e -[NSComparisonPredicate
evaluateWithObject:substitutionVariables:] + 314 4 Foundation
0x00000001003c6ae2 -[NSPredicate evaluateWithObject:] + 19 5
CoreData 0x0000000102d61d06
-[NSFetchedResultsController(PrivateMethods) _objectInResults:] + 102 6 CoreData 0x0000000102d630f7
-[NSFetchedResultsController(PrivateMethods) _preprocessUpdatedObjects:insertsInfo:deletesInfo:updatesInfo:sectionsWithDeletes:newSectionNames:treatAsRefreshes:]
+ 519 7 CoreData 0x0000000102d642d5 -[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:] + 1781 8 CoreFoundation 0x00000001035cad9c
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 12 9 CoreFoundation 0x000000010352d51d
_CFXNotificationPost + 2381 10 Foundation 0x000000010035b7fa -[NSNotificationCenter
postNotificationName:object:userInfo:] + 68 11 CoreData
0x0000000102c9048a
-[NSManagedObjectContext(_NSInternalNotificationHandling) _postObjectsDidChangeNotificationWithUserInfo:] + 74 12 CoreData 0x0000000102d16c8b
-[NSManagedObjectContext(_NSInternalChangeProcessing) _createAndPostChangeNotification:withDeletions:withUpdates:withRefreshes:]
+ 331 13 CoreData 0x0000000102c8c9cc -[NSManagedObjectContext(_NSInternalChangeProcessing) _postRefreshedObjectsNotificationAndClearList] + 108 14 CoreData 0x0000000102c8c5e4
-[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 2804 15 CoreData 0x0000000102c663cb _performRunLoopAction + 267 16 CoreFoundation
0x0000000103540dc7
CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 23 17 CoreFoundation 0x0000000103540d37
__CFRunLoopDoObservers + 391 18 CoreFoundation 0x0000000103520522 __CFRunLoopRun + 946 19 CoreFoundation
0x000000010351fd83 CFRunLoopRunSpecific + 467 20 GraphicsServices
0x00000001037ecf04 GSEventRunModal + 161 21 UIKit
0x00000001011bde33 UIApplicationMain + 1010 22 Expense_Manager
0x0000000100001d13 main + 115 23 libdyld.dylib
0x000000010420c7e1 start + 0 ) libc++abi.dylib: terminating with
uncaught exception of type NSException
Thanks in advance.

Okay i actually found out why this was happening a few days ago. There was a notification being fired off when the form dismissed which reloaded a tableView from another viewController hooked up to an FRC sharing the same context. Once I removed itself as an observer in viewDidDisappear it did not crash. :) I hope this helps incase someone is facing the same problem.

Related

Crash Core Data only in iOS 14

I work on an app which use CoreData, everything works fine on iOS 13 and iOS 14 with differents Xcode betas. But since Apple released the official release for iOS 14 and Xcode 12 I have a crash when I try to get some objects from CoreData.
guard let customers = Customer.mr_findAllSorted(by: "login", ascending: true) as? [Customer] else { return }
Console output :
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Can't get value for 'batch' in bindings {
}.'
When I try to print the object from console log with breakpoint, I have a memory address of object but when I try to print some values of this object I have this error :
error: warning: couldn't get required object pointer (substituting NULL): Couldn't load 'self' because its value couldn't be evaluated
error: Execution was interrupted, reason: internal ObjC exception breakpoint(-5)..
The process has been returned to the state before expression evaluation.
Has anyone ever had to deal with this type of errors since the official versions ?
Thanks in advance for your help.
We're seeing this too in our app. It is only reproducible with iOS 14 and apparently the latest SDKs in Xcode 12.0.1, but we don't have any solutions or answers as to why this is occurring yet.
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Can't get value for 'batch' in bindings {
}.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff2043a126 __exceptionPreprocess + 242
1 libobjc.A.dylib 0x00007fff20177f78 objc_exception_throw + 48
2 Foundation 0x00007fff2088bedc -[NSVariableExpression _expressionWithSubstitutionVariables:] + 0
3 Foundation 0x00007fff2075ac7b -[NSComparisonPredicate evaluateWithObject:substitutionVariables:] + 264
4 CoreData 0x00007fff2511ec68 -[NSDictionaryStoreMap handleFetchRequest:] + 481
5 CoreData 0x00007fff2511dfd2 -[NSMappedObjectStore executeFetchRequest:withContext:] + 230
6 CoreData 0x00007fff251e10a2 __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]_block_invoke.797 + 3219
7 CoreData 0x00007fff251d988d __55-[NSPersistentStoreCoordinator _routeHeavyweightBlock:]_block_invoke + 55
8 CoreData 0x00007fff251edf0a gutsOfBlockToNSPersistentStoreCoordinatorPerform + 182
9 libdispatch.dylib 0x000000010a6b0a88 _dispatch_client_callout + 8
10 libdispatch.dylib 0x000000010a6bfcac _dispatch_lane_barrier_sync_invoke_and_complete + 132
11 CoreData 0x00007fff251d9492 _perform + 169
12 CoreData 0x00007fff251d9740 -[NSPersistentStoreCoordinator _routeHeavyweightBlock:] + 172
13 CoreData 0x00007fff250d640e -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 1684
14 CoreData 0x00007fff250d49c2 -[NSManagedObjectContext executeFetchRequest:error:] + 885
15 CoreData 0x00007fff251a9d7f -[NSManagedObjectContext _parentObjectsForFetchRequest:inContext:error:] + 477
16 CoreData 0x00007fff251aa774 __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke + 603
17 CoreData 0x00007fff25109de8 internalBlockToNSManagedObjectContextPerform + 89
18 libdispatch.dylib 0x000000010a6b0a88 _dispatch_client_callout + 8
19 libdispatch.dylib 0x000000010a6bfcac _dispatch_lane_barrier_sync_invoke_and_complete + 132
20 CoreData 0x00007fff25109d6f _perform + 196
21 CoreData 0x00007fff25109b93 -[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:] + 175
22 CoreData 0x00007fff250d49c2 -[NSManagedObjectContext executeFetchRequest:error:] + 885
23 CoreData 0x00007fff251a9d7f -[NSManagedObjectContext _parentObjectsForFetchRequest:inContext:error:] + 477
24 CoreData 0x00007fff251aa774 __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke + 603
25 CoreData 0x00007fff25109de8 internalBlockToNSManagedObjectContextPerform + 89
26 libdispatch.dylib 0x000000010a6b0a88 _dispatch_client_callout + 8
27 libdispatch.dylib 0x000000010a6bfe11 _dispatch_async_and_wait_invoke + 175
28 libdispatch.dylib 0x000000010a6b0a88 _dispatch_client_callout + 8
29 libdispatch.dylib 0x000000010a6bef23 _dispatch_main_queue_callback_4CF + 1152
30 CoreFoundation 0x00007fff203a8276 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
31 CoreFoundation 0x00007fff203a2b06 __CFRunLoopRun + 2685
32 CoreFoundation 0x00007fff203a1b9e CFRunLoopRunSpecific + 567
33 GraphicsServices 0x00007fff2b773db3 GSEventRunModal + 139
34 UIKitCore 0x00007fff24660af3 -[UIApplication _run] + 912
35 UIKitCore 0x00007fff24665a04 UIApplicationMain + 101
36 XXXX 0x0000000106de2d69 main + 153
37 libdyld.dylib 0x00007fff20257415 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Can't get value for 'batch' in bindings {
}.'
You may set batch size to 0 [NSManagedObject MR_setDefaultBatchSize:0];, but check you performance after.

Override Core Data to-many property and return a filtered set

I’ve got an NSManagedObject with a childNodes property in its model. Now I want to override the childNodes property and return a filtered version of it, but I keep getting crashes. Here’s what I’ve got in my NSMO subclass:
- (NSOrderedSet *)childNodes {
[self willAccessValueForKey:#“childNodes”];
NSMutableOrderedSet *result = [self primitiveChildNodes];
[self didAccessValueForKey:#"childNodes”];
NSArray *filteredResult = [[result array] myCustomArrayFilteringMethod]; // let’s say this returns the first half of the array, as a contrived example
return [NSOrderedSet orderedSetWithArray:filteredResults];
}
This works alright sometimes, but I’m finding crashes like: Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSOrderedSet objectsAtIndexes:]: index 24 in index set beyond bounds [0 .. 19]’ and I’m not sure why. Call stack seems to be related to mutating a collection, but I’m mutating a copy so I’m not sure what’s happening:
0 CoreFoundation __exceptionPreprocess + 165
1 libobjc.A.dylib objc_exception_throw + 48
2 CoreFoundation -[NSOrderedSet objectsAtIndexes:] + 952
3 Foundation NSKeyValueWillChangeByOrderedToManyMutation + 568
4 Foundation NSKeyValueWillChange + 383
5 Foundation -[NSObject(NSKeyValueObserverNotification) willChange:valuesAtIndexes:forKey:] + 557
6 CoreData -[NSManagedObject(_NSInternalMethods) _excludeObject:fromPropertyWithKey:andIndex:] + 526
7 CoreData -[NSManagedObject(_NSInternalMethods) _maintainInverseRelationship:forProperty:oldDestination:newDestination:] + 254
8 CoreData -[NSManagedObject(_NSInternalMethods) _didChangeValue:forRelationship:named:withInverse:] + 567
9 Foundation NSKeyValueNotifyObserver + 347
10 Foundation NSKeyValueDidChange + 466
11 Foundation -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 118
12 CoreData -[NSManagedObject didChangeValueForKey:] + 135
13 CoreData -[NSManagedObject(_NSInternalMethods) _updateFromRefreshSnapshot:includingTransients:] + 758
14 CoreData -[NSManagedObjectContext(_NestedContextSupport) _copyChildObject:toParentObject:fromChildContext:] + 567
15 CoreData -[NSManagedObjectContext(_NestedContextSupport) _parentProcessSaveRequest:inContext:error:] + 1103
16 CoreData __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke + 364
17 CoreData internalBlockToNSManagedObjectContextPerform + 84
18 libdispatch.dylib _dispatch_client_callout + 8
19 libdispatch.dylib _dispatch_barrier_sync_f_slow_invoke + 284
20 libdispatch.dylib _dispatch_client_callout + 8
21 libdispatch.dylib _dispatch_main_queue_callback_4CF + 1738
22 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
23 CoreFoundation __CFRunLoopRun + 2073
24 CoreFoundation CFRunLoopRunSpecific + 488
25 GraphicsServices GSEventRunModal + 161
26 UIKit UIApplicationMain + 171
27 My app main + 111
28 libdyld.dylib
Any suggestions? I can’t quite figure this one out.
Just don't. Add a different method which returns a filtered copy of the original relationship. Also, for the implementation just iterate the collection and add the items you want to keep to an entirely new collection, don't copy and filter.
The crash is because the array you're filtering is actually backed by the datastore, so as you filter it it's changing the contents you're iterating with the filter, and it's screwing up the original relationship.

Removing an object at a NSMutableArray causes a crash

Attempting to remove an object at a NSMutableArray causes a crash:
2014-03-07 18:58:03.755 HomeWork Pro +[12637:70b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArrayI removeObjectAtIndex:]: unrecognized selector sent to instance 0xa2f4c20'
remove object code:
[hwArray removeObjectAtIndex:self.indexPath.row];
This only happens if I do it with self.indexPath.row, if I do it with a number it functions normally. I know the self.indexPath.row is not nil, I've NSlogged it to be sure and it turnde right. After doing that I do
[table reloadData]
to reload the UITableView data and the methods.
Any clue on what's the issue here?
Call stack
*** First throw call stack:
(
0 CoreFoundation 0x017aa5e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x0152d8b6 objc_exception_throw + 44
2 CoreFoundation 0x01847903 -[NSObject(NSObject) doesNotRecognizeSelector:] + 275
3 CoreFoundation 0x0179a90b ___forwarding___ + 1019
4 CoreFoundation 0x0179a4ee _CF_forwarding_prep_0 + 14
5 HomeWork Pro + 0x00006c88 -[HomeWork SelfDelete] + 216
6 HomeWork Pro + 0x0000711a -[HomeWork done:] + 618
7 libobjc.A.dylib 0x0153f874 -[NSObject performSelector:withObject:withObject:] + 77
8 UIKit 0x0029d0c2 -[UIApplication sendAction:to:from:forEvent:] + 108
9 UIKit 0x0029d04e -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 61
10 UIKit 0x003950c1 -[UIControl sendAction:to:forEvent:] + 66
11 UIKit 0x00395484 -[UIControl _sendActionsForEvents:withEvent:] + 577
12 UIKit 0x00394733 -[UIControl touchesEnded:withEvent:] + 641
13 UIKit 0x002da51d -[UIWindow _sendTouchesForEvent:] + 852
14 UIKit 0x002db184 -[UIWindow sendEvent:] + 1232
15 UIKit 0x002aee86 -[UIApplication sendEvent:] + 242
16 UIKit 0x0029918f _UIApplicationHandleEventQueue + 11421
17 CoreFoundation 0x0173383f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
18 CoreFoundation 0x017331cb __CFRunLoopDoSources0 + 235
19 CoreFoundation 0x0175029e __CFRunLoopRun + 910
20 CoreFoundation 0x0174fac3 CFRunLoopRunSpecific + 467
21 CoreFoundation 0x0174f8db CFRunLoopRunInMode + 123
22 GraphicsServices 0x023349e2 GSEventRunModal + 192
23 GraphicsServices 0x02334809 GSEventRun + 104
24 UIKit 0x0029bd3b UIApplicationMain + 1225
25 HomeWork Pro + 0x00008bad main + 141
26 libdyld.dylib 0x02c8a70d start + 1
27 ??? 0x00000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
It looks to me like the crash message you posted and your stack trace do not match. The stack trace shows an "unrecognized selector" crash in the making, but the crash message shows that you were attempting to insert a nil object into an array.
Neither of those things matches the line of code that you posted. (removing an object from an array.) I guess you could get an unrecognized selector error from the line of source you posted if the array wasn't really a mutable array...
EDIT:
Based on your updated question, it's clear. Your array is not actually a mutable array even though you think it is.
Post the code that creates the array.
If you're copying it somewhere, look at that code carefully. If you're loading it from a plist or an archive, be aware that mutable arrays come back as immutable when you read them back in.
What you have is an immutable NSArray. What you want is an NSMutableArray, which actually does implement removeObjectAtIndex:. Make sure your array isn't getting replaced with an immutable version at some point.

NSObjectInaccessbileExceptions while merging child context

I understand about NSObjectInaccessbileExceptions in general, and the need to avoid attempting to fault in an object that has been deleted in another managed context/thread.
However, in my user crash reports, I'm seeing an NSObjectInaccessibleException while merging/saving a child NSManagedObjectContext from a background thread (B) into my main context (A), which seems like an unusual scenario.
The only situation I can imagine that could cause such a thing is the following:
change property of object in thread/context (B)
delete object in thread/context A
save context A
save context B
merge A into B and save A -> exception raised because object doesn't exist in A.
Has anybody else seen an exception in while saving the context like this? I tried to reproduce this manually, but failed. Is there some other scenario where this could happen, and are there any tips for dealing with such?
Thanks!
Fatal Exception
NSObjectInaccessibleException
CoreData could not fulfill a fault for '0x1f019da0 <x-coredata://741E65A8-C211-470E-8194-3005F0DFA71C/TrackInfo/p265>'
0 CoreFoundation __exceptionPreprocess + 162
1 libobjc.A.dylib objc_exception_throw + 30
2 CoreData _PFFaultHandlerLookupRow + 1482
3 CoreData -[NSFaultHandler fulfillFault:withContext:] + 24
4 CoreData -[NSManagedObject(_NSInternalMethods) _updateFromRefreshSnapshot:includingTransients:] + 236
5 CoreData -[NSManagedObjectContext(_NestedContextSupport) _copyChildObject:toParentObject:fromChildContext:] + 96
6 CoreData -[NSManagedObjectContext(_NestedContextSupport) _parentProcessSaveRequest:inContext:error:] + 918
7 CoreData __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke_0 + 564
8 libdispatch.dylib _dispatch_barrier_sync_f_slow_invoke + 96
9 libdispatch.dylib _dispatch_client_callout + 22
10 libdispatch.dylib _dispatch_main_queue_callback_4CF + 228
11 CoreFoundation __CFRunLoopRun + 1288
12 CoreFoundation CFRunLoopRunSpecific + 356
13 CoreFoundation CFRunLoopRunInMode + 104
14 GraphicsServices GSEventRunModal + 74
15 UIKit UIApplicationMain + 1120
16 app main.m line 13 main
17 app start
You may try using the following line while you are creating your child context:
privateManagedObjectContext.mergePolicy = NSMergeByPropertyStoreTrumpMergePolicy

App Crashes When Navigating Away from Loading Collection View

Scenario: UINavigationViewController contains UICollectionViewControllers. Each collection view needs to get its data from a JSON API, which can take a bit of time. Then each cell in the collection view sends its own requests to the server, getting thumbnail images. (For clarity, I created a sequence diagram to show how I am doing this, not including the thumbnail requests, which I have disabled for debugging).
This is what the code looks like:
-(void)buildDisplayItems
{
NSLog(#"Collection VC (object: %#) with collection (object: %#) building display items on thread %# (main thread: %c)", self, self.showingCollection, [NSThread currentThread], [NSThread isMainThread]);
[self.showingCollection buildDisplayItemsWithPhotoBatch:self.nextBatch++]; // <-- this waits for the server request to be made, come back and get processed into arrays before returning.
self.photos = self.showingCollection.photos;
self.collections = self.showingCollection.subcategories;
// Past this point, I cannot think of how these arrays would possibly get changed to trigger the 'mutated while being enumerated' errors.
[self.collectionView reloadData];
}
The problem is if the user navigates back on the navigation view at JUST THE RIGHT TIMES, I get one of the following errors:
*** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <NSConcreteMapTable: 0x1f047c80> was mutated while being enumerated.'
*** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSSetM: 0x203f26b0> was mutated while being enumerated.'
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[3]'
To make these errors happen, I have to try 3-4 times selecting some item so its collection view gets pushed on the nav stack then quickly pressing the back button. Obviously, my first impression from the first two errors was that the data source arrays are getting modified somehow, but there's NO WAY anything I wrote is doing that. Then I thought maybe the fact that the thumbnail images for each cell is getting loaded after cellForItemAtIndexPath returns it is the problem, so I disabled that, but nothing changed.
I sprinkled some NSLogs around and found that this is happening while the collection view is making calls to its delegate methods. I made sure to add the following:
-(void)viewWillDisappear:(BOOL)animated
{
if (self.showingCollection != nil) {
[self.showingCollection cancelOperations]; //for network requests
NSLog(#"Collection VC (object: %#) will disappear", self);
}
}
-(void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
self.collectionView.delegate = nil;
self.collectionView.dataSource = nil;
self.collectionView = nil;
}
But this hasn't helped in stopping the errors. In fact, some times when the crash happens, there is no "Collection VC will disappear" log message.
The other problem is that these errors occur and the debugger stops in the main function at the UIApplicationMain line (this is with 'break on all exceptions' breakpoint), so I have no way of pinpointing how the error gets triggered. I have enabled zombies but there's no log message from them. (EDIT: Sometimes it actually stops in an empty thread, saying "error: address doesn't contain a section that points to a section in a object file")
How do I set up these collection views so that pressing the back button quickly doesn't end the world?
EDIT
How can I find out what is the collection that is being changed while being enumerated?
UPDATE
I found this SO thread talking about not being able to get stack traces. Every time I got one of the exceptions above, it'd give me a stack trace like
*** First throw call stack:
(0x327453e7 0x3a440963 0x32744ec1 0x330f72c7 0x330f769b 0x330f825b 0x330fa0c7 0x330faefd 0x33103cab 0x3498c519 0x3498d5f1 0x3498d915 0x349920d9 0x34991fe3 0x3268bacd 0x34991f97 0x3268bacd 0x34991f97 0x3268bacd 0x34991f97 0x3268bacd 0x34991f97 0x3268bacd 0x34991f97 0x3268bacd 0x34991f97 0x330fa997 0x3498bf3d 0x345c73dd 0x34303513 0x343030b5 0x34303fd9 0x343039c3 0x343037d5 0x3434a567 0x3a87febb 0x3a87fb93 0x3a898fb8 0x32fe5fc7 0x3305d24f 0x3a88d0e1 0x3a88cfa8)
libc++abi.dylib: terminate called throwing an exception
As per that thread's suggestion I implemented my own uncaught exception handler and it prints out the following stack trace:
0 CoreFoundation 0x327453ff <redacted> + 186
1 libobjc.A.dylib 0x3a440963 objc_exception_throw + 30
2 CoreFoundation 0x32744ec1 <redacted> + 0
3 Foundation 0x330f72c7 <redacted> + 422
4 Foundation 0x330f769b <redacted> + 298
5 Foundation 0x330f825b <redacted> + 202
6 Foundation 0x330fa0c7 <redacted> + 242
7 Foundation 0x330faefd <redacted> + 500
8 Foundation 0x33103cab <redacted> + 390
9 UIKit 0x3498c519 <redacted> + 128
10 UIKit 0x3498d5f1 <redacted> + 196
11 UIKit 0x3498d915 <redacted> + 88
12 UIKit 0x349920d9 <redacted> + 84
13 UIKit 0x34991fe3 <redacted> + 182
14 CoreFoundation 0x3268bacd CFArrayApplyFunction + 176
15 UIKit 0x34991f97 <redacted> + 106
16 CoreFoundation 0x3268bacd CFArrayApplyFunction + 176
17 UIKit 0x34991f97 <redacted> + 106
18 CoreFoundation 0x3268bacd CFArrayApplyFunction + 176
19 UIKit 0x34991f97 <redacted> + 106
20 CoreFoundation 0x3268bacd CFArrayApplyFunction + 176
21 UIKit 0x34991f97 <redacted> + 106
22 CoreFoundation 0x3268bacd CFArrayApplyFunction + 176
23 UIKit 0x34991f97 <redacted> + 106
24 CoreFoundation 0x3268bacd CFArrayApplyFunction + 176
25 UIKit 0x34991f97 <redacted> + 106
26 Foundation 0x330fa997 <redacted> + 166
27 UIKit 0x3498bf3d <redacted> + 124
28 UIKit 0x345c73dd <redacted> + 72
29 QuartzCore 0x34303513 <redacted> + 214
30 QuartzCore 0x343030b5 <redacted> + 460
31 QuartzCore 0x34303fd9 <redacted> + 16
32 QuartzCore 0x343039c3 <redacted> + 238
33 QuartzCore 0x343037d5 <redacted> + 316
34 QuartzCore 0x3434a567 <redacted> + 170
35 libsystem_c.dylib 0x3a87febb _pthread_tsd_cleanup + 174
36 libsystem_c.dylib 0x3a87fb93 <redacted> + 118
37 libsystem_c.dylib 0x3a898fb8 pthread_exit + 27
38 Foundation 0x32fe5fc7 <redacted> + 10
39 Foundation 0x3305d24f <redacted> + 1002
40 libsystem_c.dylib 0x3a88d0e1 <redacted> + 308
41 libsystem_c.dylib 0x3a88cfa8 thread_start + 8
1: When you navigate away from the view controller with the collection view, are you nil'ing the delegate references and data sources in the collection view so you no longer get queried?
This happens with Table Views also, the objects still persist but the data or sources do not.
2: I also recommend using #synchronized(self) when modifying the collections. So that code that sets and reads it does not clash (the enumerated crash)

Resources