Finding Memory Leaks of Legend of Tux: Difference between revisions

From LD Smith Games Workshop
Jump to navigation Jump to search
No edit summary
No edit summary
Line 32: Line 32:
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 screen.
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 screen.


When I go to the main game screen, the usage rises to 83M, 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 problems.
When I go to the main game screen, the usage rises to 83M, which is nearly the same before I made any changes.  However, 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.  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.

Revision as of 08:27, 7 November 2009

Here is a process I used to resovle a memory leak in The Legend of Tux.

This is a helpful way to find memory leaks under Windows.

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

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


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


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.

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 screen.

When I go to the main game screen, the usage rises to 83M, which is nearly the same before I made any changes. However, 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. 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.