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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
