Re: Managed Object won't dealloc even after Hit with Kitchen Sink
Re: Managed Object won't dealloc even after Hit with Kitchen Sink
- Subject: Re: Managed Object won't dealloc even after Hit with Kitchen Sink
- From: Jerry Krinock <email@hidden>
- Date: Sun, 21 Dec 2008 23:22:24 -0800
On 2008 Dec, 21, at 22:26, Quincey Morris wrote:
The only control you have in general is to *prevent* an object from
being deallocated, not to *force* an object to be deallocated.
Thank you, Quincey, I see what you mean. Probably because I have
never before seen an object ^not^ be deallocced when it was no longer
being retained, and because I've had to debug so many crashes when
objects ^are^ deallocced, it has become a tru-ism in my brain that
objects are unforgiving and ^will immediately^ disappear when their
retain count goes to 0.
Part of my testing for document-based applications has always been to
sprinkle NSLogs in the dealloc methods of any object retained to a
document, close a document, and make sure that they all log. That's
how I discovered this issue today.
// Insert a Foo without telling the undo manager
[undoManager disableUndoRegistration] ;
Foo *foo = [[Foo alloc] initWithEntity:runEntity
insertIntoManagedObjectContext:moc];
So one of the retains is your own -- you created the object, and
according to the rules, you must release it.
Yes, my mistake -- I inherited this without noticing when I cloned the
Low Level Core Data Tutorial. My real app, of course, uses -
insertNewObjectForEntityForName:inManagedObjectContext:
As noted above, one of the retains is your own. I don't know where
the other one came from, but it's possible that if you call
processPendingChanges on the moc the object will get released.
Nope, that doesn't help.
Or the object might be being cached somewhere, and there might be
nothing you can do about it.
Well, that must be the case. So it looks like, with a Core Data app,
I have to be more patient, more trusting of the memory management
contract, and abandon my favorite brute-force test.
I suppose I should use better tests. So I added this code to the end
of main:
NSLog(@"Sleeping") ;
usleep(5000000) ; // Sleep 5 seconds to give Leaks a chance.
NSLog(@"Terminating") ;
return 0;
and ran it with the performance tool "Leaks" set to analyze every 1
second.
Result: No leaks.
BUT, then I added some extra unbalanced [foo retain], re-ran the test,
expecting leaks, but no leaks :( Maybe Leaks can't analyze when a
thread is sleeping. I'll have to devise a better way to use Leaks.
_______________________________________________
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