Re: Core Data: autoreleasing an invalid object?
Re: Core Data: autoreleasing an invalid object?
- Subject: Re: Core Data: autoreleasing an invalid object?
- From: Terrence Talbot <email@hidden>
- Date: Sun, 6 Nov 2005 11:30:10 -0800
Ok, I just reread my own posting about 8 times and figured out what
was going on. It turns out that there was an obscure case in the
Media object's dealloc method that would cause a fault to fire.
(Gotta have a long talk with Dan... ;-)
It would still be instructive, I think, to get a better understanding
of what migratePersistentStore:toURL:options:withType:error does
behind the scenes to actually achieve migration. How is it that
objects are destroyed and recreated behind the scenes without messing
everything else up?
If anyone could shed light on that, that would still be really nice.
Thanks!
On Nov 6, 2005, at 11:03 AM, Terrence Talbot wrote:
During a Save As of my NSPersistentDocument, the console shows the
following complaint:
*** -[NSAutoreleasePool dealloc]: Exception ignored while releasing
an object in an autorelease pool: The NSManagedObject with ID:
0x14ba1d0 <x-coredata://D2E80BB6-2A66-4767-AF43-0C3D1FCFD67D/Media/
p1> has been invalidated.
Of course, I understand that this means that the store that this
object thinks it belongs to has been removed. I'm doing a Save As
and the document framework is calling
migratePersistentStore:toURL:options:withType:error on its
persistent store coordinator. The original store should be
invalidated. That I understand.
But why is it complaining about autorelease? Why is that causing a
fault to be fired? I thought autorelease was one of those that
would not cause a fault to be fired. (Am I misunderstanding the
troubleshooting documentation?)
To try to track this down, I set up a test document that had only
one Media object in the store and removed any of my code that
caused it to be fetched before the Save As. I went through my code
and made sure that nothing was retaining or autoreleasing this
object, apart from the standard executeFetchRequest: which, as I
understand it, returns an autoreleased array of objects.
Indeed, the first and only time that the object "comes to life" is
as a direct result of
migratePersistentStore:toURL:options:withType:error that is
completely under the direction of NSPersistentDocument.
#0 -[KTMedia awakeFromFetch] (self=0x7a45a60, _cmd=0x90a0668c)
#1 0x9403fba4 in -[NSFaultHandler fulfillFault:withContext:] ()
#2 0x94079eec in -[NSFaultHandler
_fireFirstAndSecondLevelFaultsForObject:withContext:] ()
#3 0x9407d194 in -[NSPersistentStoreCoordinator
(_NSInternalMethods) _fetchAllInstancesFromStore:intoContext:] ()
#4 0x9407d570 in -[NSPersistentStoreCoordinator
(_NSInternalMethods) _retainedAllMigratedObjectsInStore:toStore:] ()
#5 0x9407ae28 in -[NSPersistentStoreCoordinator
migratePersistentStore:toURL:options:withType:error:] ()
Nothing, as far as I can tell, in my awakeFromFetch method alters
the retain count or asks for anything to be autoreleased. No other
objects are referencing or fetching it.
The basic pattern of migration seems to be that
migratePersistentStore:toURL:options:withType:error fetches all the
objects into a new store and awakes them. It then sends
didTurnIntoFault to all the objects from the old store -- including
the Media object, above. Finally, it deallocs the objects from the
old store. My issue is that the dealloc of the Media object throws
the above exception.
I'm hesitant to file a bug: all the other objects in the store seem
to migrate without incident. It seems like it must be something in
my code, but my tracing through of release and autorelease messages
for that object suggests that the last release before the exception
is an autorelease sent from an array that is holding the Media
object. I can find nowhere that I'm adding it to an array: indeed,
I can also find nowhere that I'm sending it autorelease.
Could this be something in the way that migrate is fetching the
objects?
If anyone could shed light as to what
migratePersistentStore:toURL:options:withType:error is actually
doing and/or better ways to figure out what's going on, I would be
hugely appreciative.
Thanks,
- Terrence
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden