• entries
    422
  • comments
    1540
  • views
    488799

Memory Leak Tracker

Sign in to follow this  
jollyjeffers

87 views

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?
Sign in to follow this  


2 Comments


Recommended Comments

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

Share this comment


Link to comment
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]

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