Question

Is mystring over-released?

-(void)dealloc {
    [mystring release];
    [mystring release];
    [super dealloc];
}

I assume this will not based on [nil release] does nothing:

-(void)dealloc {
    [mystring release];
    mystring = nil;
    [mystring release];
    [super dealloc];
}

-EDIT-
Let’s say I allocate mystring in init and release it in doSomething:

-(id)init {
    if (self = [super init]) {
        mystring = [[NSString string] retain];
    }
    return self;
}
-(void)doSomething {
    [mystring release]; // for some good reason
    // ...etc
}

Now to avoid over-releasing in dealloc based on my example above do I have to explicitly do this in the doSomething method?

-(void)doSomething {
    [mystring release];
    mystring = nil; // <- is this mandatory to avoid over-releasing in dealloc?
}

The big question is do I have to explicitly set it to nil when I release it somewhere else in the class to avoid over-releasing in dealloc?

So could I do as many releases as I want in dealloc based if I explicitly set to nil in doSomething?

-(void)dealloc {
    [mystring release];
    [mystring release]; // <- does nothing because mystring explicitly nil?
}

Answer 1

For your first example, the answer is probably!

In general, each object that holds a reference to another object should retain it until they’re done, then call release once, however in some highly exotic (and generally poorly written) cases this may not hold. If you retain the object x times, you need to release it x times, and other cases of poor memory management. But best practice, yes, one retain, one release, don’t release more than you retain!

There are two risks with over-releasing like this:

The first is if the first release call makes the refcount of mystring equal to 0, it will be dealloc’d, and then you’re sending a message to a piece of memory that is no longer a valid object. Objective-C doesn’t really like this, and may react in a variety of ways, including CRASHING. Sending messages to nil, kosher, messages to things dealloc’d, not so much.

The second is if the refcount isn’t zero, you just released someone else’s reference, so at some point in the future, an object that has a reference to mystring may think that reference is valid and it won’t be because it was dealloc’d when the refcount hit zero on a subsequent release call. This will be harder to detect than the previous error, where a debugger will at least show you the real area the problem originates from in the stack frame trace.

Your second example is correct – sending a message to nil does nothing. If you fear you’ll do things like this, be sure to set your variables to nil after releasing.

EDIT: Yes. That’s what you should do if you intend to release in more than one place like that, however depending on the application, you might consider using an auto-release pool.