Question

I am pretty much a newbie to objective-c and as I started to program, I did not really grasp how to properly release objects. So, my project being an introduction into the world of Objective-c, I omitted it completely. Now, however, I think this project evolved in that it is too much of a pity to just leave it at that. So, all the allocs, copys and news aside, I have serious problems with understanding why my project is still leaking so much memory.

I have made use of the leaks tool in Instruments (look at screenshot), and it shows me that whole array of objects that are leaked. My question now: Is this something to be worried about, or are these objects released at some point ? If not, how do I find the cause of the leak ? I know that if I press cmd + e it shows me the extended detail window, but which of these methods should I look in ? I assume that it is my own methods I have to open up, but most of the times it says that i.e. the allocation and initialization of a layer causes the problem.

That said, I would like to know how to effectively detect leaks. When I look at the leaks bar of instruments, at the initialization of my game layer (HelloWorldLayer) a biiiig red line appears. However, this is only at it’s initialization… So, do I have to worry about this ?

Here is the screenshot:
link to file (in order to enlarge) -> https://i.stack.imgur.com/QXgc3.jpg

EDIT:
I solved a couple of leaks, but now I have another leak that I don’t quite understand :

for (int i = 1; i<=18; i++) {
            NSMutableDictionary *statsCopy = (NSMutableDictionary *)CFPropertyListCreateDeepCopy(kCFAllocatorDefault, (CFDictionaryRef)stats, kCFPropertyListMutableContainers);
            NSNumber *setDone = [num copy];
            [levels setObject:statsCopy forKey:[NSString stringWithFormat:@"level%d", i]];
            [levels setObject:setDone forKey:@"setDone"];
            [statsCopy release];
            [setDone release];
        }

He happens to detect a leak with the deep copy, even though I release it…

Answer 1

The screenshot shows that there’s a dictionary allocated in -[Categories init] that never gets released. Actually, there are many (2765) such dictionaries.

That method seems to be invoking -[NSDictionary newWithContentsOf:immutable:]. The stack trace here may be somewhat misleading due to optimizations internal to Cocoa. That’s not a public method. It’s probably called by another NSDictionary method with a tail call which got optimized to a jump rather than a subroutine call.

Assuming there’s debug information available, Instruments should show you the precise line within -[Categories init] if you double-click that line in the stack trace.

Knowing where it is allocated is not the whole story. The Categories class may manage ownership of the object correctly. Some other class may get access to it, though, and over-retain or under-release it. So, you may have to track the whole history of retains and releases for one of those objects to see which class took ownership and neglected to release it. Note, this has to be done for one of the leaked dictionaries, not one of the malloc blocks that was used internally to the dictionaries. Go down two lines in the table for some promising candidates. Toggle open that line to see the specific objects. Double-click one or click the circled-arrow button next to its address (I forget which) to see the history of retains and releases.