Question

It seems like I keep asking the same questions, memory related. My current code works exactly as I intend it, but I cannot figure why I am showing a leak here in Instruments.

-(NSDate *)startTimeAndDate {
    NSDate *dateToReturn = nil;
    if (startTimeAndDate != nil) {
        dateToReturn = [startTimeAndDate retain];
    } else { //is currently nil, this will be the initial setting
        //return default time if we have a working date
        if (finishTimeAndDate != nil) {
            dateToReturn = [[self dateFromDate:finishTimeAndDate withNewTime:defaultStartTime]retain];
        } else {
            //return the default time with today's date if we have nothing set as yet
            dateToReturn = [[self dateFromDate:[NSDate date] withNewTime:defaultStartTime] retain];
        }
        //save the initial setting
        self.initialStartDateAndTime = [[dateToReturn copy] autorelease];
    }
    [startTimeAndDate release];
    startTimeAndDate = dateToReturn;
    return startTimeAndDate;
}


-(void)setStartTimeAndDate:(NSDate *)inStartTimeAndDate {

    BOOL initialAssignment = NO;
    if (startTimeAndDate == nil) {
        initialAssignment = YES;
    }

    if (startTimeAndDate != inStartTimeAndDate) { //skip everything if passed object is same as current
        //check that the start time is prior to finish only if finish time has been entered
        NSDate *dateToSetStartTo = nil;
        if (finishTimeAndDate != nil) {
            if ([inStartTimeAndDate earlierDate:finishTimeAndDate] == inStartTimeAndDate) {
                // use the new time, it is earlier than current finish time
                dateToSetStartTo = [inStartTimeAndDate retain];
            } else { //start time is not earlier then finish time
                // the received entry is invalid, set start time to 1 default interval from finish
                dateToSetStartTo = [[finishTimeAndDate dateByAddingTimeInterval:-self.defaultTimeInterval] retain];
            }
        } else { //finish time is nil
            // use the new time without testing, nothing else is set
            dateToSetStartTo = [inStartTimeAndDate retain];
        }
        [startTimeAndDate release];
        startTimeAndDate = dateToSetStartTo;
    }
    if (initialAssignment) {
        self.initialStartDateAndTime = [[self.startTimeAndDate copy] autorelease];
    }
}

So far as I can see, I am balancing all retains with release or autorelease. The leak appears to be caused on the first pass only. I have a view controller, it creates my model (wherein this code lies) and sets a start date, nothing else is done at that point. If I close that view controller at that point, Instruments shows that I am leaving the date object as a leak.

I placed a NSLog to show retain count at dealloc and, sure enough, it has retain count of 2 before my final release is called, leaving a retain count of 1 when it should have been destroyed. It is always the same regardless if I close immediately after initialization or set and get a hundred times. retainCount is 2 prior to my final call to release in dealloc.

I have been looking at this all weekend and cannot figure where I’ve gone wrong.

To clarify, the initial call is to set the startTimeAndDate property. At that point all other fields are nil or 0 if not objects. That startTimeAndDate object appears to be the leaking object.

Answer 1

Dam, ignore what I said. I just went through the code again and you’re right. I think you are basically being burned by the complexity of the code. I found it quite difficult to follow, especially with the number of properties. I think what I would do at this stage is to copy the code to a unit test and run it from there. Then you can better test and debug it. I would recommend GHUnit if you do not already have unit testing in place.

The other thing that occurs to be is that there is code executing somewhere else in your program that is retaining the date. Therefore triggering the leak. For example if inStartTimeAndDate is coming in with a retain count of 1, but is not released by the code that called the setter then you could end up with startTimeAndDate with a retain of 2.

Having said that, here’s my rewrite of the getter in an attempt to clarify whats going on:

-(NSDate *)startTimeAndDate {

    // If we have it, bail out fast.
    if (startTimeAndDate == nil) {
        return startTimeAndDate;
    }

    // Is currently nil, this will be the initial setting
    NSDate *dateToReturn = nil;
    //return default time if we have a working date
    if (finishTimeAndDate != nil) {
        dateToReturn = [self dateFromDate:finishTimeAndDate withNewTime:defaultStartTime];
    } else {
        //return the default time with today's date if we have nothing set as yet
        dateToReturn = [self dateFromDate:[NSDate date] withNewTime:defaultStartTime];
    }
    //save the initial setting
    self.initialStartDateAndTime = [[dateToReturn copy] autorelease];

    startTimeAndDate = [dateToReturn retain];
    return startTimeAndDate;
}

The main reason for this re-write was that it appeared that if there was a startTimeAndDate then the code was doing this:

dateToReturn = [startTimeAndDate retain];
...
[startTimeAndDate release];
startTimeAndDate = dateToReturn;

Which seemed a little pointless because it’s effective doing a retain, release and self assignment. It would work, but there’s less chance of a bug if we leave it out.