• entries
422
1540
• views
488809

# Direct3D Memory Leak Tracker is Alive!

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.

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...

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?

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]

## Create an account

Register a new account