Why is this Objective-C code allocating GBs of RAM, releasing it later, and not reporting any leaks?

I have inherited some code, and it looks like this:

- (bool)makeOneLevel:(int)nummines objects:(int)numobjects
{
    [field release];
    state = gameWait;
    field = [[MineField alloc] createLevel:nummines objects:numobjects];

   开发者_C百科 if([field rating] == -1)
    {
        return false;
    }
...

There is always one MineField allocated. Whenever you make a new field, the first thing the function does is release the old one. If the function succeeds in making a MineField, then it returns true.

I also have this:

while(numsaved < self.makeNumber)
{
    while(![mineView makeOneLevel:self.makeNumMines objects:self.makeNumObjects])
    {
    }
    { 
        //saving code here
    }
    numsaved++;
}

Which calls the function until it creates a valid MineField. This all works. But it allocates GBs of RAM while doing it. But the Leaks tool finds no leaks, and when the outer while finishes and the OS gets control back, all that RAM is deallocated just fine.

Am I doing something wrong with the MineField allocation, or should I be looking elsewhere in the creation process?

Without knowing the internals it's impossible to say for sure, but the behavior you're describing sounds like -[MineView makeOneLevel:objects:] is internally allocating and autoreleasing objects. Since the AppKit default event loop creates and cleans up an autorelease pool for each event it processes, everything does end up going away eventually, but not until the event is finished processing (e.g, after your method exits).

The easiest solution will be to wrap your own autorelease pool around the while() loop, and drain it either every time around the loop or periodically. If you aren't too scared of the internals of the method you're calling in the loop, though, you may be better off just finding where it's autoreleasing objects and fix it (by making it explicitly release objects when appropriate).

If you do not get any better answers, try using the heap profiler from Google perftools to track down where the huge allocations are happening.