Slight Memory Leak, or is it?

I have found what looks to be a slight memory leak, but I am not sure.

Here is the output from three trips into level_001, and back to the level select screen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Level Select Screen
        MemUsage: 376.1982421875
        TexMem:   0.417024
 
Changing Scene to Level001
        MemUsage: 500.7431640625
        TexMem:   7.306496
 
Level Select Screen
        MemUsage: 415.1025390625
        TexMem:   3.046656
 
Changing Scene to Level001
        MemUsage: 501.6572265625
        TexMem:   7.306496
 
Level Select Screen
        MemUsage: 415.7666015625
        TexMem:   3.046656
 
Changing Scene to Level001
        MemUsage: 502.8525390625
        TexMem:   7.306496
 
Level Select Screen
        MemUsage: 417.4931640625
        TexMem:   3.046656

I'd say you are looking at at least 2 memory leaks - 0.66 upon exiting your level, and 1.0 entry.

Those are not negligible leaks.

Since your texture memory is static, it is almost certainly a set of table entries you referenced from multiple locations. Look for places where you set a variable with another variable. Yes, that is probably a lot of locations.

Thanks Simon.

What am I looking for specifically? Making sure all my vars are nil'd out? Period.

Is that actually a best practice? Just niling out all vars to make sure they get collected correctly?

I will start digging.

setting a variable to nil doesn't matter - if you loop through your same code and re-set the variable, it doesn't make a copy. No new memory allocation = no memory leak.

On the other hand, re-building tables will generally re-allocate memory. What you are looking for is a place where you do something like this (could be spread far apart, of course)

function StartGame

t = {}

for i=1, 100 do
t[i] = i
end

Each time you start your game, you will create a new table t. If you can simply re-initialize your data (putting the "t = {}" outside the fuction), that is a big win.

Ideally, in a game starting over and over, you don't need to re-initialize your tables - only the data inside them.

500 seems on the high side. How does this run on the device?

Thanks Simon. I will take a look through for such offenders.

@crssmn - Why would 500 be high? If the number reported is in kb, as I have been led to believe, half a MB hardly seems outrageous...is that way out of line? I would not be surprised if it is, or if I am doing something completely bad, and causing this issue myself.

Maybe it's not high. Typically when I check my system memory on the apps I have written 300-400 tends to be on the high side, though my apps tend to be simple games. Is Kb the units used?

Thanks for everyone's help on this. I really appreciate it.

It looks like I tracked it down, finally. Well, I tracked down most of it. At least I eliminated the memory slowly marching up.

Turns out I was assuming that the director class would properly handle cleaning out groups and the child display objects. I think director was handling the display objects, but leaving the display groups hanging around.

When I added code to removeSelf on all the display groups, and then nil them out, my memory seems to have stabilized. The numbers going from the LevelSelectScreen and Level_001 are now consistent between trips in and out.

I will consider this a win, at the moment. The true test will come when I populate the changes to all the levels :)

hi mike4 I wonder how did you delete all your display group and make your memUsage stable??
I have the same problem like yours, i have 4 different characters and with each character have their own sprite movement, the problem is after I change to another scene to load another character then my memory is always going up high and ricardo said to use localGroup.clean = function() but it didnt help anything and my "collectgarbage" still up the memory size.
Please help me with this....

@seaweedbread

What I do, is I have a function that gets called to bring in a new scene. In that function, before I bring in the scene, I added code to nil everything that I created in the current scene (including variables), that way everything is ready for garbage collection.

I found another thread that recommends niling out the new() function that is required by director. Doing this, removed more of the memory in use.

It is also recommended to nil out any objects you have created using the ui class. I still need to add that in to my code, but I am guessing that it will remove all of my increasing memory.

Here is the thread I am talking about:

http://developer.anscamobile.com/forum/2011/03/07/potential-serious-memory-leaking-issue

And here is a copy of my function that brings in my LevelSelect screen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
function BringInLevelSelect()
        mm.removeRuntimeListeners();
        mm.cancelAllTimers();
        mm.cancelAllTransitions();
        timer.cancel(tmpTimer);
        TextCandy:CleanUp();
        ParticleCandy:ClearParticles();
        State:removeEventListener ( "change", State );
        State:removeSelf();
        State = nil;
        Background:removeSelf();
        Background = nil;
        Foreground:removeSelf();
        Foreground = nil;
        Midground:removeSelf();
        Midground = nil;
        Game:removeSelf();
        Game = nil;
        GUI:removeSelf();
        GUI = nil;              
        success = nil; tryAgain = nil; score = nil;
        new = nil;
        director:changeScene("LevelSelectScreen","crossfade");          
        collectgarbage("collect");
end

Yes nilling out new helps alot. Also if you only require your ui class and what ever classes you use once in your main.lua. instead of on each level. Your initial memory rises when you start the game, but memory from changing scenes drops too. :)

thanks all ;)

views:1714 update:2011/9/28 21:38:26
corona forums © 2003-2011