2017-02-15 7 views
3

Ich bekomme einen seltsamen Coredata-Fehler in der Produktions-App und konnte den Crash-Bericht bekommen.Coredata stürzt beim Abrufen ab

Sein mit der folgenden Meldung Abstürzt manchmal

*** Fehler für Objekt 0x17e400000: Freigeben nicht zugeordneten Zeiger

*** Fehler für Objekt 0x17fd03730: pointer umverteilt wird zugeteilt wurde

nicht

Und hier ist der 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 

Es ist auf dem Hauptthread geschehen und ich bin verwirrt, wie man das debuggt. Sieht jedoch nach einem Speicherproblem aus. Auch während der Verwendung von Instrumenten zeigt es einige Lecks in der App, wenn es über NSPrivateQueueConcurrencyType.

Auf der Suche nach ein paar Erkenntnissen über das Festnageln.

App MagicalRecord Weitgehend verwendet, und hier ist der Codeblock in der App, die oben Absturz führt. Es ist nur ein normaler Abruf von Main Thread. Interessanterweise stürzt es zufällig ab, dh es stürzt nicht immer ab, aber manchmal stürzt es beim Fetch ab.

NSPredicate *filterPredicate = [NSPredicate predicateWithFormat:@"code == %@ and pid == %@", aCode,pid]; 
Permission *aPermission = [Permission MR_findFirstWithPredicate:filterPredicate]; 
+0

einige Code einfügen. – kb920

+0

@Sj THIS MIGHT HELP-: http://stackoverflow.com/questions/15253966/getting-the-error-pointer-bing-freed-was-not-allo-cated-set-a-breakpoint-in –

+0

Wäre hilfreich, wenn Sie könnten einige 'fetchRequest' &' Objekt updates' bezogenen Code – ystack

Antwort

0

Kern-Datum managedObjectContext und Managed Thread-sicher nicht - weder zum Schreiben oder für zu lesen. Wenn Sie jemals gegen diese Regel verstoßen, kann das Kerndatum jederzeit abstürzen - nicht unbedingt, wo/wann der Verstoß aufgetreten ist. Selbst wenn Sie im Hauptthread sind und auf einen Kontext zugreifen, der für den Hauptthread entworfen wurde, kann er dennoch abstürzen, wenn Sie irgendwo anders in Ihrer App etwas falsch gemacht haben.

3

Zugreifen (schreiben oder lesen ) ein verwaltetes Objekt auf einem beliebigen anderen Thread als die Managed Object Kontextschlange & undefiniertes Verhalten führt führt zu zufälligem seltsam abstürzt.
Es sieht aus wie Ihre Managed Object Context wurde mit NSPrivateQueueConcurrencyType & Ihre Durchführung fetch auf der Main Queue erstellt. Dies ist die Quelle der seltsame Absturz. Auch
Sie können entweder initialisieren MOC mit NSMainQueueConcurrencyType oder nisten alle Ihre fetchRequests innerhalb [MOC performBlock:{...}]