Wednesday, August 28, 2013


So, yesterday's successful memory cleanup was mostly motivated by the observation that, according to the Task Manager, my game was leaking memory at about 70K per second.  I was expecting to find it was my fault, but now that there are no memory leaks... it's still happening!

So, on to more data gathering.

Using HeapWalk, and dumping the entire contents of memory every frame, I discovered that... well, there's definitely a leak, but it's not one of the game allocations.

First, I pause the game, so there is nothing happening during Update, and we're only Rendering the same frame over and over again.  Then, I put a breakpoint in HeapAlloc (the base level Windows allocator that everything else eventually calls).

So, there are a tiny number of (expected) allocations of mine... a bunch from NVIDIA's driver...

And finally I notice some allocations happening from my file monitor, which is a really handy class that I set up that stores a list of files, their last-modified times, and a callback function pointer.  Once each frame, I check to see if any of the files were modified, and if they were, trigger the callback.  This makes live asset changes really easy.

Apparently, in one case, I was not calling FindClose after calling FindFirstFile to check the current file time.

Fixed this, and my memory usage is nice and stable.  Yay, no more sucking up all available memory if I leave the game running for a few hours!


  1. Ok, so you've find YOUR memory leaks. Now come help me with mine! haha

    Thanks for the tip using 'HeapWalk'!

  2. Yes, HeapWalk was very useful. I thought I was going a bit nutty when the "regular" memory dump wasn't showing any leaks, but temporary allocations kept moving higher in memory each frame. Then I realized malloc was just sitting on top of HeapAlloc and I wasn't getting the whole picture.


Note: Only a member of this blog may post a comment.