Memory Leak Problem

Started by
5 comments, last by Anders2 12 years, 11 months ago
Hi all,

I'm working on D3D9 device enumeration. Everyting works fine (I can say "fine" because my enumerator outputs same results with DX Caps Viewer). But I've a problem with memory leak. Even if I destroyed everything in my app. I'm sure I'm calling all the destructors, ReleaseCOMs etc.

Here's a list of what I do:
1) Opening Windows Task Manager and jumping "Performance" tab. Looking at SD Usage. It's now 789 MB.
2) Creating a windowed D3D9 application. Doing something. Rendering blah blah. Still looking at SD Usage. It's now 811 MB.
3) Exiting that application. Looking at SD Usage. It's now 789 MB. It means, my application gives back the memory it used. Right?

The Problem:
But, if I create a fullscreen application instead of a windowed one, especially with different sizes from my desktop (e.g. my desktop is 1920 x 1080 and I'm creating a 1280 x 768 fullscreen app), SD Usage is over 789MB after I closed my app!

Why/how does it occur? Is that normal? If not, how can I deal with this?

Thanks in advance.
There's no "hard", and "the impossible" takes just a little time.
Advertisement
By SD, do you mean swap drive / page file? Usually, it'll expand to accommodate an increase in the memory requirement (such as opening new programs), but it may not reduce in size until you close down more programs than you opened; it really depends on what Windows decides. It shouldn't be a cause for alarm...

Task manager may also not be the best way to check for memory leaks... It'll tell you the really obvious ones (i.e. program is running mostly idle/not loading any new resources, yet the memory usage keeps going up), but it won't help you identify them... If you're using MSVC++ (Express or Studio), you can use their very useful memory leak detection feature: http://msdn.microsoft.com/en-us/library/x98tx3cf(v=VS.100).aspx. It's able to tell you which resources haven't been freed by the time the program ends, as well as the line on which you allocated them.
One way to make sure you released everything corretly is to activate the debug runtime of directx and check for the output after exiting the app. If you forgot or failed to release anything related to directx, it will show you some error messages while trying to clean up the leaked memory. This won't help you finding out what exactly is wrong, but it will tell you if there really is a leak with directx or not.
Remember as well that this might not be your program at fault. Windows itself may be deciding to keep the D3D (or other) DLLs loaded in memory in case you want to use them again sometime soon.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

@The King2:
Now tried with debug runtimes (and checked "Break on Memory Leaks" checkbox) and I got no errors, no leaks caused by D3D.

@kiwibonga:
Thank you for your reply. I've tried with memory leak checking option and I got a big list :) But I'm sure I'm deallocating/destroying/releasing everything :S Strange.

I've looked into some DX samples provided by SDK and tested'em. No memory leaks occur in'em; but it's so difficult to follow the code line by line while debugging (due to DXUT usage, it's very complicated I think).

Thank you all of your replies.
There's no "hard", and "the impossible" takes just a little time.
Everything you allocate yourself should be automatically released by the OS when your program exits, so this is not something you normally need to worry over. It's possible that you may have a driver bug that only manifests in fullscreen modes, that's about all I can think of right now.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Another good tool that may be useful to search for misc problems with your (or another) application is
Microsofts Application Verifier (AppVerifier). You can download it here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18

A quick how to (for xp) can be found here (maybe not up to date):
http://support.microsoft.com/kb/286568
I think there's a good help file included as well.

Start with basic tests, this app has some quite complex tests that can bring your computer to the cpu speed of a stone :-)
(If I remember correct the memory tests (at least heap) is included in basic tests)

This topic is closed to new replies.

Advertisement