Sj.
Sj.

Reputation: 1724

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];

Upvotes: 9

Views: 4958

Answers (2)

ystack
ystack

Reputation: 1805

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:{...}]

Upvotes: 11

Jon Rose
Jon Rose

Reputation: 8563

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.

Upvotes: 3

Related Questions