I was using the ‘Resource Monitor’ on Windows (memory tab) to look at my project, and noticed that the memory (private, working, commit) was going up continuously.
After commenting out most of the code, I checked again, and saw the same thing.
Is this normal ?
And why would this be happening ?
How do I know when to be worried about memory leaks in my project ?
Does it go up and then suddenly goes back to the initial or near initial levels after a while ?
That’s something I see a lot happening while using Process Explorer.
Does it actually go off and break because it runs out of memory or something like that ?
I did some more tests, but since I don’t know anything about memory ‘things’, I’m not exactly sure what it all means. So I’ll just give the numbers for commit, working set, and private mem in the Resource Mgr (all in MB).
I tested the Flash target (Flash Player 24). and Windows target (debug versions).
The game runs at 60FPS.
Empty game with just the FPS class (and peak memory) :
- Flash startup : 68.7 - 71.7 - 50.8
- Flash after 10 minutes : 71.5 - 81.2 - 56 (stable)
- Windows startup : 65.7 - 87 - 60
- Windows after 10 minutes : 94 - 113 - 86 (stable)
Full game with FPS class (and peak memory) :
- Flash startup : 80.5 - 84 - 63
- Flash after 10 minutes (not playing) : 83.2 - 93.2 - 71.4 (stable)
- Flash after 10 minutes (playing) : 99.5 - 106.0 - 79.8 (stable)
- Windows startup : 83 - 102 - 75
- Windows after 10 minutes (not playing) :94 - 113 - 86 (stable)
- Windows after 5 minutes (playing) :138 - 158 - 130 (still going up & then crashes with a null pointer ref error (that I don’t have in Flash))
Never use test results from debug-mode.
Debug is slower, has a bigger memory footprint, and so on.
If you want “reliable” data do it in release.
With System.totalMemory / System.freeMemory you can trace it in your code.
The memory consumption is fluctuating because of the GarbageCollector, but as long as you program has a “fixed/stable max”, you are fine.
Yeah, I figured debug wouldn’t give me the best results, but I just wanted to get an indication of what was happening to memory because of some animation problems I was having (which are now fixed).
I was just surprised to see that memory keeps going up for 10 minutes before it becomes stable …
The HXCPP garbage collector tries not to collect aggressively. It means that it has an internal threshold of what it thinks is too much memory before it will start spending time cleaning things up. This can make it look like there is a memory leak, and can sometimes make testing more difficult.
You can run GC yourself, and that can sometimes make it easier to measure, using
I wish people would write more about these kinds of things. It’s hard to know if things are ‘alright’ if you have nothing to compare it to …
I did the testing again, but this time with the release versions. As I suspected, the numbers are different, but the trend is the same :
Is it possible to have something wrong with the Windows target, but not with the Flash version ? I noticed that Flash stabilizes after a while, but Windows keeps going up and finally crashes.
EDIT : Yes, Windows definitely crashes !
When I have finished the game (it’s a small point&click game), but I leave it running, the game suddenly crashes after a while.
I then get the option to debug, and VS is opened. I see this message :
'FF.exe' (Win32): Loaded 'C:\Windows\SysWOW64\usermgrcli.dll'. Loading disabled by Include/Exclude setting.
The thread 0xa8c has exited with code 0 (0x0).
Unhandled exception at 0x00FF3262 in FF.exe: 0xC0000005: Access violation reading location 0x00000000.
The program ' FF.exe' has exited with code 0 (0x0).
How do I find out what’s going on ?
Do you remove all of your event listeners? We do not have full support for weak references in the C++ target, so you need to remove listeners manually.
Do you make any network requests? What kind of rendering do you use?
Ah … I didn’t realize weak references don’t work fully in C++. Thanks for mentioning !
Ok, I think I cleaned up the event listeners as much as I can (and also fixed a bug where I added a listener instead of removing it), and memory usage in the C++ target is now much better (and stable).
I also figured out why the C++ target was crashing.
I have a sound on a loop at the very end of the game. When I restart the sound, I had a typo in the name (not when I first call the sound). Since memory of the C++ target continued to go up, I left the game running a lot longer than the Flash game … and so I never got the null pointer exc in the Flash game.
Testing games is such a pain.