memory leaks?
Blitz3D Forums/Blitz3D Programming/memory leaks?
| ||
| What is the best way to check for memory leaks? Also with data, is it nesasary to free that info like in types? If so how? |
| ||
| Blitz itself has no memory leaks. It frees up everything when it is terminated. |
| ||
| Right. I know that, but what about while it is running, and between levals? How do I know that everything was removed that should have bin? An example of this would be a screensaver I made a while back. I made it into an executable and left it running for 11 hours. Then when I came back to it, it was moveing very slow. And when I tried to exit it, my computer froze up. My guess is it froze up while trying to free up everything on exit, but I don't know. So if I have a game and it is is not corectly deleting types and data, It will get slower and slower with each leval. What I am asking is a way to track Types instances,Data index,and asosiated variables like x#=entityx#(player\ship), where x# is the asosiated variable. And if I have say dim(1000) and say it refers to enemy ships, each ship gets deleted when hit by a player bullet and again at the end of the leval. But how do I know for sure that all the data was deleted. |
| ||
| The blitz debugger can tell you the value of variables, which may be helpful. |
| ||
| Well there's no magic wand, you just keep track of them. I find a simple way to test is to add a function which counts the number of type instances for each type and writes them to a file. Then I run the game, do nothing and quit. Copy the debug file somewhere. Then Run it again, play through a few times, try and cover everything at least twice, then quit. That usually shows me if I've forgotten to delete anything. EG: In my pool game, if I played two games, and the log showed 32 ball type instances, I'd know I'd forgotten to delete the balls after each game ( as there are 16 balls in a game, two games.. you do the math ) You could also write the log every time you step in and out of the main menu to see where type instances are being created and not deleted. Graphics not freed will usually bite you in the bum quite noticeably, but displaying the AvailVidMem() can help track down niggling texture and mesh freeing errors. |
   |