Re: [Pyobjc-dev] Bug Fixed!!! Dealing with alloc / init oddities

[Ronald O. <ous...@ci...>]

Bill,

The 'fix' was not your change to 'objc_support.m', but the change to 
'selector.m' (the one I'm so unhappy about ;-()

The problem is that NSMutableArray isn't really following the Cocoa 
refcounting conventions. This can be demonstrated using a simple 
Objective-C program:

#import <Foundation/Foundation.h>

int main(void)
{
         id x;
         printf("class: %p\n", [NSMutableArray class]);
         printf("alloc: %p\n", x = [NSMutableArray alloc]);
         printf("init: %p\n", x = [x init]);
         printf("alloc: %p\n", x = [NSMutableArray alloc]);
         printf("init: %p\n", x = [x init]);
}

The output on my system:
  class: 0xa07ec7b8
  alloc: 0x875a0
  init: 0x8e7a0
  alloc: 0x875a0
  init: 0x8e7c0

Note that return value of the two calls of alloc is the same, and 
different from the return value of the corresponding init calls. 
Appearently 'alloc' just returns a kind of factory object, and 'init' 
is the one that actually allocates memory.

Further investigation shows that the return value of 'alloc' is a 
'NSPlaceholderMutableArray'. Actually it is probably that class and not 
an instance of it. Both 'x->isa->name' and 'x->isa->isa->name' are 
'NSPlaceholderMutableArray', if 'x' where an object I'd expect the 
second to be 'NSObject'.

I'm glad to find that the problem with NSArray is caused by a feature 
of Cocoa and is not a memory corrupting bug in PyObjC itself. That 
doesn't make it easier to actually fix it of course, but at least we 
can now start to think about how to really solve this instead of 
hunting down an elusive memory corruption
error.

Ronald