views:

61

answers:

2

I've created a graphing application that calls a web service. The user can zoom & move around the graph, and the program occasionally makes a decision to call the web service for more data accordingly. This is achieved by the following process:

The graph has a render loop which constantly renders the graph, and some decision logic which adds web service call information to a stack.

A seperate thread takes the most recent web service call information from the stack, and uses it to make the web service call. The other objects on the stack get binned.

The idea of this is to reduce the number of web service calls to only those appropriate, and only one at a time.

Right, with the long story out of the way (for which I apologise), here is my memory management problem:

The graph has persistant (and suitably locked) NSDate* objects for the currently displayed start & end times of the graph. These are passed into the initialisers for my web service request objects. The web service call objects then retain the dates.

After the web service calls have been made (or binned if they were out of date), they release the NSDate*.

The graph itself releases and reallocates new NSDates* on the 'touches ended' event.

If there is only one web service call object on the stack when removeAllObjects is called, EXC_BAD_ACCESS occurs in the web service call object's deallocation method when it attempts to release the date objects (even though they appear to exist and are in scope in the debugger).

If, however, I comment out the release messages from the destructor, no memory leak occurs for one object on the stack being released, but memory leaks occur if there are more than one object on the stack.

I have absolutely no idea what is going wrong. It doesn't make a difference what storage symantics I use for the web service call objects dates as they are assigned in the initialiser and then only read (so for correctness' sake are set to readonly).

It also doesn't seem to make a difference if I retain or copy the dates in the initialiser (though anything else obviously falls out of scope or is unwantedly released elsewhere and causes a crash).

I'm sorry this explanation is long winded, I hope it's sufficiently clear but I'm not gambling on that either I'm afraid. Major big thanks to anyone that can help, even suggest anything I may have missed?

To hopefully clear things up a bit, here is some pseudo(ish)code...stuff (excluding locks and initialisers):

NSMutableArray* requests;
NSDate* start, end;

-(void)webServiceThread
{
    if([requests count] > 1)
    {
        [self doRequestWithParams:[requests lastObject]];
        [requests removeAllObjects];
    }
}

-(void)render
{
    if(conditions for another web service call are met)
    {
        WebServiceRequest* new = [[WebServiceRequest alloc] initWithDates:start :end];
        [requests addObject:new];
        [new release];
    }

    [self doRendering];
}

-(void)touchesEnded
{
    [start release];
    [end release];
    start = [[NSDate dateSinceTimeInterval:chartLeft] retain];   //Ficticious NSDate Method names for example.
    end = [[NSDate dateSinceTimeInterval:chartRight] retain];
}

And then in the web service call object:

NSDate* startDate;
NSDate* endDate;

-(void)initWithDates:start :end
{
    startDate = [start retain];
    endDate = [end retain];
}

-(void)dealloc
{
    [super dealloc];

    //The following two lines cause EXC_BAD_ACCESS if this is the only object on the request stack. If they are commented, however, memory is leaked if this is not the only object on the request stack.
    [startDate release];
    [endDate release];
}
A: 

Problem fixed by putting [super dealloc]; at the end of the desctructor. Credit to Toon Van Acker.

Out of interest; can anypne say if the same principle applies to other methods such as [super init]?

Tobster
You MUST call [super dealloc] last. As soon as it is called, you cannot guarantee that any of your ivars are valid anymore because [super dealloc] eventually calls [NSObject dealloc] which frees the memory and makes it available for reuse. [super init] must be done before any of your own initialisation code and its return value assigned to self.
JeremyP
A: 

It's safer to call [super dealloc] last in dealloc, although not required. It is possible that [super dealloc] releases things that other things, such as KVO, rely on.

http://stackoverflow.com/questions/909856/why-do-i-have-to-call-super-dealloc-last-and-not-first

Toon Van Acker