Finding Memory Leaks of Legend of Tux

From LD Smith Games Workshop
Revision as of 08:45, 7 November 2009 by Levidsmith (talk | contribs)
Jump to navigation Jump to search

Here is a process I used to resovle a memory leak in The Legend of Tux. This process was done in Windows, so finding memory leaks in Linux will be somewhat different, but the overall process should be the same. For Linux, I would recommend using "ps -ef | grep <program name>" to determine how much memory your program is using.

First, start Task Manager (Ctrl-Alt-Delete => Start Task Manager)

Click the Processes tab

Start your application, and the name of your executable should show up in the list


In the screen below, I see that my program is using 13M of memory, and half the CPU

Lotux taskman001.jpg

When I go to the stage select screen, it still uses about half the CPU, but the memory used jumps to 26.5 M

Lotux taskman002.jpg

I select a stage, and the memory used again increases to 87M

Lotux taskman003.jpg


I quit the stage, return to the title screen, and select another stage, which increases the memory used to 168 M. I was able to very quickly run up the amount of memory used to 300+ M by quitting to the title screen, selecting a stage, and repeating.

Lotux taskman004.jpg

Since the memory increases occur when a new screen is loaded, I have a good clue that makes me believe that the memory leak is due to not freeing the memory used to store the music data buffer.

I checked the audio.c file that I am using to handle the SDL_Mixer commands, added "Mix_FreeMusic(music);" and "music = NULL;" code before the audio is loaded. I recompiled and tried the program again, but the memory still significantly increased between screens.

My next guess is that it is due to the SDL_Surface objects not being free'd.

I checked the main lotux.c file, and I found that there were images being created at the beginning of the gameLoop function that were not being free'd. Originally, the gameLoop function was the main function of the game, which was only called once in the program. However, the gameLoop function can now be called multiple times in the game, every time a level is selected. I moved all the image creation calls to the LoadSprite method (which is called at program startup), and I created a freeSprite method which is called before the program exits.

I tried running the program again.

Now there is a big jump to 63M memory usage when the program starts up, however this is not a bad thing. All images are now being loaded at startup, instead of being reallocated and reloaded on every time the gameLoop is called.

Lotux taskman005.jpg

When I go to the main game screen, the usage rises to 83M, which is nearly the same before I made any changes. This is expected, since I am loading all images at the start and free'ing them just before the program exits. If I wanted, I could free the images for the title screen and stage select screen before moving to the main game loop. However, the extra processing and load required to do that dynamically probably isn't worth the small amount of memory I would save from it. However if I needed to get the program to run smoothly on an old system (with maybe less than 256M of RAM), I would need to unload the title screen and stage select images, and reload them when those are needed.

Lotux taskman006.jpg

After exiting to the title screen, and returning to the game screen the amount of memory used only increased to 102M. Repeating this process results in the amount of memory being used increasing by 16M each iteration (title screen => stage select => game loop). So there is still a problem, but the jump in amount of memory usage is not quite as huge. A further investigation will need to be pursued to determine any remaining memory leak problems. The arrays used to store the collision and title data for all the maps is a possible source of the remaining memory leak.

Lotux taskman006.jpg