Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Coredata crash while fetching

I am getting some weird coredata error in the production app and I was able to get hold of the Crash Report.

Its Crashing with the following message at times

*** error for object 0x17e400000: Freeing unallocated pointer

*** error for object 0x17fd03730: pointer being reallocated was not allocated

And here is the stack trace

Crashed: SQLQueue 0x13ff15250 for datastore.sqlite
SIGABRT ABORT 0x0000000183986014

0 libsystem_kernel.dylib    __pthread_kill + 8
1   libsystem_pthread.dylib  pthread_kill + 112
2   libsystem_c.dylib   abort + 140
3   libsystem_malloc.dylib  _nano_vet_and_size_of_live + 330
4   libsystem_malloc.dylib  nano_free + 220
5   libsqlite3.dylib    sqlite3_finalize + 244
6   CoreData    -[NSSQLiteConnection _finalizeStatement] + 100
7   CoreData    -[NSSQLiteConnection releaseSQLStatement] + 52
8   CoreData    newFetchedRowsForFetchPlan_MT + 2420
9   CoreData    _executeFetchRequest + 72
10  CoreData    -[NSSQLFetchRequestContext executeRequestUsingConnection:] + 60
11  CoreData    __52-[NSSQLDefaultConnectionManager handleStoreRequest:]_block_invoke + 260
12  libdispatch.dylib   _dispatch_client_callout + 16
13  libdispatch.dylib   _dispatch_barrier_sync_f_invoke + 84
14  CoreData    -[NSSQLDefaultConnectionManager handleStoreRequest:] + 208
15  CoreData    -[NSSQLCoreDispatchManager routeStoreRequest:] + 288
16  CoreData    -[NSSQLCore dispatchRequest:withRetries:] + 200
17  CoreData    -[NSSQLCore processFetchRequest:inContext:] + 108
18  CoreData    -[NSSQLCore executeRequest:withContext:error:] + 504
19  CoreData    __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]_block_invoke + 4512
20  CoreData    -[NSPersistentStoreCoordinator _routeHeavyweightBlock:] + 276
21  CoreData    -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 408
22  CoreData    -[NSManagedObjectContext executeFetchRequest:error:] + 572
23  CoreData    -[NSManagedObjectContext(_NestedContextSupport) _parentObjectsForFetchRequest:inContext:error:] + 456
24  CoreData    __82-[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:]_block_invoke + 584
25  CoreData    internalBlockToNSManagedObjectContextPerform + 92
26  libdispatch.dylib   _dispatch_client_callout + 16
27  libdispatch.dylib   _dispatch_barrier_sync_f_invoke + 84
28  CoreData    _perform + 232
29  CoreData    -[NSManagedObjectContext(_NestedContextSupport) executeRequest:withContext:error:] + 188
30 CoreData -[NSManagedObjectContext executeFetchRequest:error:] + 572
31  *MY_APP*    NSManagedObject+MagicalRecord.m line 50__67+[NSManagedObject(MagicalRecord) MR_executeFetchRequest:inContext:]_block_invoke

It did happen on the main thread and I am puzzled on how to debug this. Looks like a memory issue though. Also while using instruments its showing some leaks in the app when it comes across NSPrivateQueueConcurrencyType .

Looking for some insights on nailing it down.

App is using MagicalRecord Extensively and here is the code block in the App Which leads to above crash. Its just a normal fetch from Main Thread. Most interestingly it crash randomly, ie it doesn't always crash but at times it crashes while doing a Fetch.

NSPredicate *filterPredicate = [NSPredicate predicateWithFormat:@"code == %@ and pid == %@", aCode,pid];
Permission *aPermission = [Permission MR_findFirstWithPredicate:filterPredicate];
like image 254
Sj. Avatar asked Feb 15 '17 12:02

Sj.


2 Answers

Accessing (Write or Read) a Managed Object on any thread other than the Managed Object Context Queue causes undefined behaviour & leads to random weird crashes.
It looks like your Managed Object Context was created with NSPrivateQueueConcurrencyType & your performing fetch on the Main Queue. This is the source of the weird crash.
You can either initialize MOC with NSMainQueueConcurrencyType or nest all your fetchRequests inside [MOC performBlock:{...}]

like image 79
ystack Avatar answered Oct 10 '22 02:10

ystack


Core-date managedObjectContext and managedObjects are not thread-safe - neither for writing or for reading. If you ever violate this rule core-date can crash at any time - not necessarily where/when the violation occurred. So even if you are on the main thread and accessing a context designed for the main thread it can still crash if you did something wrong somewhere else in your app.

like image 34
Jon Rose Avatar answered Oct 10 '22 00:10

Jon Rose