macOS Watching Autoreleasepool releases after event loop

[Mac Player]

My Nib has an AppController instance which handles auto allocated NSStrings. I redefined NSString dealloc to

@implementation NSString (deallocdamit)

- (void) dealloc
{
    NSLog(@"Im going to die %@", self);
    [super dealloc];
}

@end

But the message is never print in the console. Are the string not being released at the end of the loop?

 

[Eraserhead]

I really wouldn't worry about it.

 

[tacoman667]

If I remember correctly, the dealloc gets called when the application is closed but you would need to call garbagecollector exclusively. Otherwise the item will stay in memory as a null reference and be first on the list of being overwritten. That is a "primitive" type is it not? You did autorelease anyways, right? You relinquished your releasing rights when you declared that so the collector may have taken control from you.

I do not know all teh in's and out's.

 

[tacoman667]

I have been reading my new Cocoa Programming for Mac OS X 3rd Ed. book and it stated that if you use garbage collection, ie. the autoreleasepool, then dealloc method is never called. Use the retain counts method of memory management and you will see that method being called.

 

[Mac Player]

Forgot to say I'm not using GC.

 

[Krevnik]

Two things seem odd... you are overriding dealloc in a category, which seems bizarre. Does that even work for other methods? And in some ways, you should be glad it doesn't call it, since if NSString did redefine it, then you just told NSString to leak memory like a sieve.

But also, NSString isn't the actual guaranteed class that a string will wind up being. The real class for most strings is NSCFString, not NSString.

A lot of core data classes do this in Cocoa.

 

[Mac Player]

When the app starts in can see the input manager's path being freed. I know that i am leaking memory but i just wanted to see how NSApplication auto pool management work.

 

[Krevnik]

If you want to do that, you are probably better off writing a small app and using your own classes to test it with. Overriding the behavior of a public API like NSString won't work the way you think, because you don't control the code. It doesn't help that NSString never returns an NSString when you create one.

As for how autorelease pools work, think of each thread having a 'stack'. When you allocate a pool, it pushes that pool onto this stack. When you release it, it pops it off the stack. This may not be 100% accurate, but it is what I have seen in terms of behavior so far (EDIT: This is actually accurate, I checked the docs, and it does use a stack the way I describe).

When you autorelease an object, it adds it to the pool currently on the top of this stack. Then, when you release the pool, it sends a release message to every object in the pool. If you autorelease an object multiple times, then the pool will send multiple release messages. That is really all it does.

The idea being that if you alloc & init an object, it has a retain count of 1. Then if you want to return this object as a return value you autorelease it. This ensures the object continues to live long enough that the method that called you can use the object, but that it will get a release message later on to balance out your init. If the method that called you wants to keep the object, it should retain it, and then release it later when it is done with it.