Re: [Pyobjc-dev] Reference Counting

[Michael T. <li...@mj...>]

On Apr 8, 2004, at 2:20 PM, Ronald Oussoren wrote:

> I found what's causing this. Due to the way python and PyObjC work 
> this code above is equivalent to:
>
> 	NSObject* oldpool;
> 	NSObject* pool;
>
> 	while (1) {
> 		oldpool = pool;
> 		pool = [[NSAutoreleasePool alloc] init];
> 		[oldpool release];
>
> 		[NSArray array];
> 	}
>
> If you run this code you'll notice lots of messages on stderr: It's 
> complaining that an NSArray instance is leaked due to missing an 
> autorelease pool.
>
> You don't see that in python because the objc module creates a pool 
> when it is loaded, this is necessary to be able to use Cocoa at all. 
> ... Hmm, to be more precise it used to be required, I suppose we could 
> nowadays require the user to create a pool. Something else to look 
> into.
>
> I'm not sure why Cocoa behaves like this, but this might be the 
> intended behaviour. The documentation for NSAutoreleasePool explictly 
> mentions that pools behave like a stack, I suppose the implementation 
> doesn't like it when you pop the second highest entry of that stack.

I think popping the second highest element on the stack should be fine. 
That can happen in Objective-C if control leaves a pool's "scope" 
because of an exception. Popping the outer (lower on the stack) pool 
should cause it to empty the inner (higher on the stack) pool.

So I think what's happening is that the [oldpool release] is popping 
both pools, causing the NSArray to be put into the top-level pool 
created by the objc module. The top-level pool is never emptied inside 
the loop, so it *looks* like the NSArrays are being leaked.

--Michael