0

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];
}
Tobster
  • 345
  • 1
  • 3
  • 12
  • It sounds to me like there is one release to many. From your explanation it sounds like it's non-obvious where this extra release occurs. I think somewhere along the way an autorelease must have snuck in, which you missed. It would help if you could post the relevant code -- all assignments, retain and releases of the dates. – T . Apr 22 '10 at 13:49
  • As a small note, it's generally safer to call `[super dealloc]` last in `dealloc`, although not required. http://stackoverflow.com/questions/909856/why-do-i-have-to-call-super-dealloc-last-and-not-first – T . Apr 22 '10 at 13:58
  • Thanks for your reply, pseudocode has been added (actual code is massively longer; could also be part of the problem). Autorelease idea didn't occur to me, but everything has a storage method (currently retain) specified where applicable. – Tobster Apr 22 '10 at 13:58
  • Jesus s*** the bed; your suggestion to put [super dealloc] at the end has actually fixed the problem!!! That was a very long post for that, but thanks! – Tobster Apr 22 '10 at 14:01
  • Well, I don't see anything wrong with your pseudo code... All that comes to mind is that you say the dates are `readonly`. I assume that means you're using properties for them. Are they `readonly, retain`? – T . Apr 22 '10 at 14:04
  • I'll just post that as an answer then, if you don't mind :P – T . Apr 22 '10 at 14:06

2 Answers2

0

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
  • 345
  • 1
  • 3
  • 12
  • 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 Apr 22 '10 at 14:59
0

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.

Why do I have to call super -dealloc last, and not first?

Community
  • 1
  • 1
T .
  • 4,874
  • 3
  • 23
  • 36