Re: Problem using my own managed object context
Re: Problem using my own managed object context
- Subject: Re: Problem using my own managed object context
- From: Frank Illenberger <email@hidden>
- Date: Mon, 08 Feb 2010 08:02:32 +0100
Hello Gideon,
in contrast to the warnings in Apple's documentation, using a custom subclass of NSManagedObjectContext is fine and often necessary to enrich the context information of your managed objects. We have successfully using this technique for complex applications since the first version of CoreData. But you have to be aware that during a store migration - which is performed during a "Save As..." in NSPersistentDocument - CoreData allocates its own temporary context which will always be of the class NSManagedObjectContext. I regard this as a conceptual bug in CoreData not being able to specify the context class used during a migration. But in most cases, the custom context logic and state is not needed during the migration so that a few "isKindOfClass" checks are sufficient to deal with the changing context class.
That said, your crash looks like you under-retain or over-relase your context. Have you tried using Instruments.app to record the retain/release history of the migration context? And by the way: Have you considered switching your app to garbage collection?
Cheers
Frank
Am 08.02.2010 um 00:42 schrieb Gideon King:
> I'm having a problem that shows up when I do a Save As on my core data based app. Saving my document is fine, so long as I save under the same name (either with a new document or one I have loaded), but when I do a save as, I get the following error:
>
> malloc: *** error for object 0x114e74cb0: pointer being freed was not allocated
>
> and the stack trace shows:
>
> #0 0x00007fff813a811c in objc_msgSend ()
> #1 0x00007fff81bed2ec in -[NSManagedObjectContext(_NSInternalAdditions) _dispose:] ()
> #2 0x00007fff81becfd2 in -[NSManagedObjectContext dealloc] ()
> #3 0x00007fff81bdc0a3 in -[NSManagedObjectContext release] ()
> #4 0x00007fff81eb1246 in _CFAutoreleasePoolPop ()
> #5 0x00007fff85db22f8 in -[NSAutoreleasePool drain] ()
> #6 0x00007fff81c30eb9 in -[NSPersistentStoreCoordinator migratePersistentStore:toURL:options:withType:error:] ()
> #7 0x00007fff84a817e2 in -[NSPersistentDocument writeToURL:ofType:forSaveOperation:originalContentsURL:error:] ()
> #8 0x0000000100032409 in -[NMPersistentDocument writeToURL:ofType:forSaveOperation:originalContentsURL:error:] (self=0x100d5b050, _cmd=0x7fff84d2a59e, absoluteURL=0x119c2ee30, typeName=0x100819d00, saveOperation=1, absoluteOriginalContentsURL=0x100a12640, error=0x7fff5fbfdea8) at /Users/gideon/Development/svn/trunk/mac/Source/NMPersistentDocument.m:306
>
> If I enable zombies, it shows
>
> *** -[NSManagedObjectContext _processReferenceQueue:]: message sent to deallocated instance 0x11ec0e6b0
>
> Now initially I thought the issue must be that I was not removing observers or something like that (which may still be true), but the interesting thing is that in my subclass of NSPersistentDocument, in the init method, I change the managed object context to my own one as follows:
>
> NSPersistentStoreCoordinator *coordinator = [[self managedObjectContext] persistentStoreCoordinator];
> NMManagedObjectContext *context = [[NMManagedObjectContext alloc] init];
> [context setPersistentStoreCoordinator:coordinator];
> [self setManagedObjectContext:context];
> [context release];
>
> ...but that is not reflected in the stack trace - it is always talking about an ordinary NSManagedObjectContext.
>
> So I think maybe there is a problem with me using my own custom managed object context in this way, and perhaps when it migrates the persistent store, maybe somewhere there it reverts to a standard managed object context or something.
>
> Does this sound like a likely scenario? Or am I barking up the wrong tree?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden