• entries
    422
  • comments
    1540
  • views
    488809

Direct3D Memory Leak Tracker is Alive!

Sign in to follow this  
jollyjeffers

139 views

Right, only a quick entry (again) - I've gotta get my Penguin Suit on and head off to the Graduation Ball shortly...

Last entry I mentioned about the use of IDirect3DResource9::SetPrivateData() and its ability to do auto-magical memory leak reporting. Take the following example:

LPDIRECT3DTEXTURE9 pTex = NULL;

CreateTextureWrapper( pd3dDevice, 128, 128, 0, 0, D3DFMT_X8R8G8B8, D3DPOOL_MANAGED, &pTex, NULL );

SAFE_RELEASE( pTex );


Shouldn't be a problem, and all thats changed is pd3dDevice->CreateTexture() becomes CreateTextureWrapper( pd3dDevice, ...). Simple use of #define's means that it resolves to the "native" call in a release build but in debug it'll "tag" it with memory tracking information.

The above example generates the following output when the application closes:

INFO: 1 resources were tracked, the following were not correctly released:
INFO: NO tracked resources were leaked!


Now, if we instead choose to comment out the SAFE_RELEASE() call and introduce a memory leak, we get:

INFO: 1 resources were tracked, the following were not correctly released:
Texture Details:
Dimensions: 128x128, 0 mip-map levels in format 22
Usage: 0, pool 1
Texture was created on line 188 of 'OnCreateDevice()'
[k:\internet\gamedev.net\directx forums\testbed\testbed.cpp]


Which I think is a whole lot more useful than the 2500 lines of debug output of memory addresses and stack traces [grin]

I've got to do some proper testing and I need to add handlers for other resources and functions (currently only textures are trackable), but the core concept is working well.

I'll see about posting up a proper explanation of this code as a longer journal entry next week when I've got it finished. Code will be available to anyone who wants it.

I'll probably be integrating it with XML logging technology for my personal projects - so I get a nicely printed message to the log file along with other general stack-trace type information that I normally get. Within reason there would be no reason why you can't tag it with other information that'll help you track down when/where/why it was created.
Sign in to follow this  


3 Comments


Recommended Comments

Whoa, that's really sexy. I'm looking forward to teh coeds - I'll have to integrate a nice system like that into the next incarnation of my framework; I have a feeling I'm fighting a losing battle with unfreed texture allocations right now.

Stupid monsters hiding under the sink...

Share this comment


Link to comment
Nice technique. If I understand it correctly, you can even put the filename of the texture inside the private data? No?

By the way.. You have everything up to a k: drive?

Share this comment


Link to comment
Code should be available in the near future - just gotta make the time today/tomorrow to finish it off [smile]

Quote:
By the way.. You have everything up to a k: drive?
Yeah, and an 'L' drive when I plug in my USB pen drive.

A - floppy
C - Primary HDD
D - DVD-RW
E - CD-RW
F - Secondary HDD Partition 1
G - Secondary HDD Partition 2
H - Secondary HDD Partition 3
I - RAID-1 HDD Partition 1
J - RAID-1 HDD Partition 2
K - RAID-1 HDD Partition 3
L - USB Pen Drive

[grin]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now