iOS Can anyone help me understand this performance tool (Leaks) data please?

[BananaDuffle]

Hi guys,

Running the "Leaks" performance tool on my OpenGL ES game shows a 3.3kb spike at about 6 seconds after launch(see attached image).

Playing the game for around 10 min, while in the performance analysis tool, memory usage rises from 3.98mb to 4.06mb; but no further leaks are found.
During this time I am constantly moving the player character, opening & closing menu's and making sure I'm covering all the ground in the current play area and viewing all objects and textures I currently have incorporated in my game.

There are currently no sounds and textures account for about 1/2mb of resources.

But that little spike has me worried, as I'm new to XCode and not so savvy at reading the output of the leaks tool... is it a minor oddity or cause for concern?

 

[PhoneyDeveloper]

Click on the little Icon at the bottom that looks like a rectangle, half filled and half empty. That shows a stack trace on the right side of the window. Click on one of the leaked blocks to select it.

You will now see the stack trace to the place where the leaked block was created. This isn't the place where it leaked. You're of course looking for your own code in the stack trace to see where this block was allocated in order to figure out what it is. Now you have to figure out why it leaked.

It's very common on iPhone to have container views, arrays and dictionaries etc. If you leak one array you will also leak all of its contents, which will lead to a bunch of objects shown as being leaked. If you fix the container object leak it will fix the leak for all of its contained objects.

The General Blocks that you show as being leaked I'm pretty sure are allocated by malloc.

 

[BananaDuffle]

Thank you

I was foolishly ignoring a "warning: taking address of temporary" while parsing a string into a vector of shorts.

And thats shaved a few KB off of my memory usage.

BUT having made that change the red spike is still there ... except non of my methods are in the stack trace any more when inspecting the leaky section (fixing the "address of temporary" issue seemed to have removed them).

The ones in the stack trace are:
* thread_start, _p_thread_start & malloc from libSystem.B.sylib
* operator new(unsigned long) from libstdc++.6.dylib
* And a bunch og stuff from libGLProgramability.dylib

Does the presence of malloc suggest I'm not disposing of things correctly somewhere?

Based on the appearance of that red spike so soon after launch on the time line is it a safe bet that my problem lies during the loading of textures, levels, instantiation of objects rather than something in the main game or draw loops?... or is that not what the visual representation is suggesting?... as I'm currently reading the red maker as "you leaked x Kb's @ this time", is that correct?

 

[PhoneyDeveloper]

The red (I always thought it was brown but what the hey) peak is when the leaks tool determined that the leak happened. The stack trace for the leaked blocks shows when the blocks were allocated, in this case, when malloc was called. So yes, the leak is happening early in your app startup. (The way the leaks tool works I think it can only tell when a leak happens not where in your code.)

I think the functions you mention indicate that the blocks were allocated on a background thread, which may or may not be important. I don't know what libGLProgramability is. Is this an Apple library or a third party library? Since it's a dylib I would guess it's an Apple lib but I don't find it on my computer. At any rate it may be a leak in that library or it may be that that library returns something to your code that you should be free-ing. I don't know which.

ObjectAlloc includes a history of every memory block in the app. It reports when it was allocated and when it was free-ed. If you look closely at the time when your leak occurred and closely at the ObjectAlloc history you can usually determine what was happening when the leak occurred.