Slight Memory Leak, or is it?

Solar2D General Questions/Discussion
#1

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:

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

Notice the TexMem values are consistent, but the MemUsage keeps going up. Granted, this is a small movement up each time, but it is still there. The MemUsage will continue to keep going up the longer the game is played.

Some particulars, I am using the latest Director class (1.3), I am also using TextCandy for displays, although the increase is still there if I remove all the TextCandy code.

I have made sure to cancel all transitions, cancel and nil all timers, nil any un-needed variables, and remove all Runtime listeners.

Is there something else I should be looking at? Is the slight increase expected, and something that just comes as a natural overhead of Corona?

I am showing the output for going in and out of one level, because the numbers should be the exact same on each of the scenes (Level Select, and Level_001). Since all the levels are setup the exact same way, if I solve the issue on level one, all the remaining levels will work correctly.

Can anyone provide somewhere to look for this leak?

Mike Hovland
Blue Rocket Labs
[import]uid: 5317 topic_id: 11449 reply_id: 311449[/import]

#2

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. [import]uid: 65996 topic_id: 11449 reply_id: 41633[/import]

#3

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. [import]uid: 5317 topic_id: 11449 reply_id: 41697[/import]

#4

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.

[import]uid: 65996 topic_id: 11449 reply_id: 41774[/import]

#5

500 seems on the high side. How does this run on the device? [import]uid: 10903 topic_id: 11449 reply_id: 41777[/import]

#6

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. [import]uid: 5317 topic_id: 11449 reply_id: 41780[/import]

#7

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?

[import]uid: 10903 topic_id: 11449 reply_id: 41781[/import]

#8

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 :slight_smile:

[import]uid: 5317 topic_id: 11449 reply_id: 41919[/import]

#9

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… [import]uid: 64917 topic_id: 11449 reply_id: 43864[/import]

#10

@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:

[lua]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[/lua] [import]uid: 5317 topic_id: 11449 reply_id: 43901[/import]

#11

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. :slight_smile: [import]uid: 39088 topic_id: 11449 reply_id: 44103[/import]

#12

thanks all :wink: [import]uid: 64917 topic_id: 11449 reply_id: 44303[/import]