Memory Leak Tracker

Published June 14, 2006
Advertisement
Right, quick update...

Work was coming along quite nicely with the D3D memory leak tracker, but I hit a problem. The embarrassing part is that it only popped up yesterday - its such an obvious use-case that I should've spotted it MUCH earlier.

Lost devices.

The backing to my leak checking only knows when the application starts and finishes, the basic principle being that any recorded resources still alive when the application finishes are leaks. But a lost-device scenario is relatively arbitrary and could never happen or could happen lots of times.

I haven't found a particularly graceful way of "hooking" into the Lost-Device call. I'd imagine the only method is via Muhammad's D3D hooking code, that would be a pretty powerful method but is probably going to be a lot of extra complexity.

It also seems that DXUT does some behind the scenes work to help a broken application survive the reset. My leak checker seems to get in the way and brings the whole program crashing down [lol] But I'm hoping thats just a simple bug on my part rather than a design/architecture level problem.

The only thing I've thought of so far today is to require that the application developer add in some sort of manual hook in their OnLostDevice() code. I could expand this to a more generic "check-point" function that can allow the manager to spot leaks much closer to the source, which could be useful...

Whilst this could work its prone to mistakes (e.g. putting it in the wrong place or forgetting it entirely). The best bit about the code I've already got is that it doesn't require many changes to the application's code - its mostly transparent.

Anyone think of any clever ideas? Would having to put a "checkpoint" into your code be a bad thing?
Next Entry Untitled
0 likes 2 comments

Comments

jollyjeffers
Hmm, just looked at Muhammad's hooking code. Looks like theres a lot of potential there... I could easily hook the ::Create**() calls and add in my private data to flag the resource. I can also hook Present() for a D3DERR_DEVICELOST return code.

The trade-off is that the DLL has no context to work with - mine currently stores the __FILE__, __FUNCTION__ and __LINE__ - adding other app-specific state variables is also a nice possibility...

So, to get the best of both worlds I'd have to hook the DLL and have an app-side component it seems (hacking in data across the shared handle sounds risky)...

Bugger.

Jack
June 14, 2006 08:55 AM
remigius
In Managed DirectX you could hook the existing device.DeviceReset and device.DeviceLost events to be notified of these occurrences. Doesn't normal DirectX have some equivalent, a callback function somewhere maybe?

An alternative might be to use Muhammad's hooking code to keep track of the created/disposed resource handles in some hashmap and have the application fill in the app specific data there if desired. It's not as elegant as using the private data of the D3D resources, but it might be a whole lot safer. I haven't got a clue how this should be implmented in C++, but this page looks helpful.

You could also use the hook the other way around. IIRC Muhammad's sample uses a named pipe to pump data into DirectInput. Can't you just sent a message when a device is lost from the hooking DLL through a pipe on which your tracker is listening on the other end? This seems to be the easiest, most elegant and safest way to do this.

Hope this somehow makes sense [smile]
June 14, 2006 10:11 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement