releasing class' static array « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

releasing class' static array

(12 posts) (5 voices)

Started 5 months ago by counciler
Latest reply from counciler

Tags:

No tags yet.

counciler
Member

So here's the beef. I'm trying to create a class variable that's a mutable array. I add some conditions to the init and dealloc methods that see if the the array isn't a nil value and init it and dealloc it accordingly. However, when I release the array it doesn't actually seem to be releasing it. I ran the retain count through NSLog to look at it, and sure enough, before and after the release its count remains at 1. Is this a memory leak or is this behavior by design? This is my isolated code.

HelloWorldScene.m

- (void)init{

     fooObject *foo1 = [fooObject new];
     fooObject *foo2 = [fooObject new];
     [foo1 release];
     [foo2 release];
}
@end

@implementation fooObject

static NSMutableArray *fooArray;

- (id)init{
     if (self == [super init]) {
          if (!fooArray) {
          fooArray = [NSMutableArray new];
          NSNumber *fooNum = [NSNumber numberWithInt:0];
          for (int x = 0; x < 4; x++) {
               [fooArray addObject:fooNum];
          }
     }
}
return self;
}

- (void)dealloc{
     if (fooArray) {
          NSLog(@"retainCount1: %i", [fooArray retainCount]);
          [fooArray release];
          NSLog(@"retainCount2: %i", [fooArray retainCount]);
          fooArray = nil;
     }
     [super dealloc];
}
@end

Posted 5 months ago #

marcelofabri
Member

- (id)init{
     if (self == [super init]) {
          if (!fooArray) {
          fooArray = [NSMutableArray new];
          NSNumber *fooNum = [NSNumber numberWithInt:0];
          for (int x = 0; x < 4; x++) {
               [fooArray addObject:fooNum];
          }
     }
}
return self;
}

Shouldn't it be

if (( self = [super init] ))

Posted 5 months ago #

timTheMystic
Member

You may want try using this to alloc array instead.

fooArray = [[NSMutableArray alloc] init];

Posted 5 months ago #
hactar
Member

Apple's documentation explicitly states that you should not rely on the retainCount property as this may not give you the numbers that you expect. Internally the cocoa framework may call a retain for a block, autorelease, etc, etc

As for your code:

Why are you doing an if (!fooArray) in the init method? It's the init method, fooArray is undefined at this point in time.

Your code should crash on NSLog(@"retainCount2: %i", [fooArray retainCount]); as the object would be dealloced at [fooArray release]; so fooArray now points to a dealloced object. If it's not then theres an additional retain somewhere that you have not posted.

Posted 5 months ago #
clarus
Member

Yes there's that "self =" issue which should definitely be fixed, but it's not the reason for what he's seeing.

After you call [fooArray release] on an object with a retain count of 1, it's immediately released. So, when you check it again, you're actually looking at invalid data. There's no leak, you're just referencing an invalid pointer.

I'd really suggest using the [[XXX alloc] init] approach rather than new. It's a good habit to get into with Objective-C, since as soon as you need to use a custom initializer, you'll have a mix of calling your own code both ways, and I'm sure you've already got a mix of using new and alloc/initXYZ for other classes you use.

@hactar, you typed faster than me on the retain/release explanation. fooArray will always be nil in the init message though, since Objective-C initializes all iVars to 0/nil/false.

Edit: ..oh wait.. a 'class" variable? Like a static global? Yeah, that would be undefined unless he has it initialized to something like
static NSMutableArray *fooArray = nil;
when he defines it. If he does that, it will be fine though.

Posted 5 months ago #
counciler
Member

I did forget to put the declaration of the variable in the sample code above, I fixed it now.

Initializing something with the "new" command I thought was the same as " alloc] init]", just with less typing. About 80% of the time I'm using something like alloc] initWithStuff] anyways so it's not a big deal to just use the long default init as a safety measure I suppose. It doesn't fix the problem I'm having, though.

But you know hactar, I think that you may have given me the answer I need. If apple says not to rely to heavily upon that then I'll have to trust that the issue is with some behind the scenes stuff. Calling retainCount like I do doesn't crash the app, the log in the debugger console says I have a retain count of 1 both times. Calling release twice, however will crash the app. Also, in my main app, calling the retainCount at a different time after I release it in the dealloc method will sometimes crash the app as well, though not always. So it probably is by design and has to do with autorelease.

Also, clarus, when you say there's something wrong with "self=" I guess you're talking about if(self ==[super init]). What's wrong with that? I thought I read about that from apple documentation, I could be wrong, though.

Posted 5 months ago #
clarus
Member
if(self ==[super init]) should be if(self =[super init])

because it's shorthand for:
```
if ((self = [super init]) != nil)
{
}

or:

self = [super init];
if (self != nil)
{
}
```
In other words, you're setting self to the init'd value and seeing if it's nil.

So, now that you've added it, I believe that this is indeed uninitialized until you store something in it:
static NSMutableArray *fooArray;

You should do this:
static NSMutableArray *fooArray = nil;

new is equivalent to [[xxx alloc] init] but my point was that when you want to do [[Blah alloc] initWithLevel: 4] you won't be able to use new anyway, so you might as well just use alloc/init instead of a combination of the two.

Also, in my main app, calling the retainCount at a different time after I release it in the dealloc method will sometimes crash the app as well, though not always. So it probably is by design and has to do with autorelease.

Your array in this case is not an autoreleased object, so as soon as you release the last retain, it will be deallocated. For autoreleased objects, the release actually happens sometime later, so it can cause strange crashes when you access it in other code.
Posted 5 months ago #
counciler
Member

Alright, I see why I should declare my init methods like that. Makes sense, though I had to add an extra set of parenthesis because of a compiler warning.

It's not a big deal adding "=nil" to my declaration of my static variables, but I thought all values are nil by default, which is why the condition if(!fooArray) runs the code I specified.

Posted 5 months ago #
clarus
Member

I just checked and it does seem that globals are initialized to nil. A class's iVars are as well. Definitely not local variables, though. So, I guess it's optional if you want to be explicit about that.

Posted 5 months ago #
hactar
Member

Never rely on the compiler to initialize variables or set them to nil. Many compilers do so, some do not, some only do so when specific compiler settings are set up to do so.

- Apple may change default behavior
- Apple may change to a different compiler (they already switched from gcc to llvm)
- You may run into a template where the author turns off such compiler options
- You may program using a different framework or programing language in your future life where the compiler does not set things to nil.
- etc, etc, etc

Trust me, it's a thing you'll learn the easy or the hard way at some point in future: ALWAYS initialize your variables yourself.

Posted 5 months ago #
clarus
Member

Well, the iVar initialization is part of Objective-C. http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html

Creating Instances
...The alloc method dynamically allocates memory for the new object’s instance variables and initializes them all to 0—all, that is, except the isa variable that connects the new instance to its class.

It sounds like the globals one might be too, although I've never relied on that:
http://stackoverflow.com/questions/990817/objective-c-ints-always-initialized-to-0

The post above does make a good point about C++ objects not being initialized to 0, though. And probably more relevant, if you may ever port the code to a different language, it will pay to be explicit.

Posted 5 months ago #
counciler
Member

Alrighty. I appreciate the help. I've learned a few things here. I've still got a ways to go, though. And I'm glad I didn't learn this lesson the hard way.

Posted 5 months ago #

RSS feed for this topic

Reply

You must log in to post.