# D3D Memory Leaks & 'lAllocID' Values

This topic is 4821 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Evening all, One of those classic moments where I've completely confused myself [sad] I know I've done this before (somehow) but I've forgotten. In testing out some memory leak checking stuff, I modified one of the DXSDK samples so it didn't release one of the ID3DXMesh objects. Consequently you get:
Direct3D9: (INFO) :MemFini!
Direct3D9: (ERROR) :Memory still allocated!  Alloc count = 149
Direct3D9: (ERROR) :Current Process (pid) = 00000e28
Direct3D9: (ERROR) :Total Memory Unfreed From Current Process = 45808 bytes

Now, I was pretty sure I remembered that the lAllocID field for each (ERROR) could be used to find the offending object. There are lots more (ERROR) entries than actual leaks because it's reporting the owners of the leaked object as well. So, I fire up the control panel:
And plug in my 11 values for the "Break On AllocID" field. Run my application again, and they all point to either the Direct3DCreate() or CreateDevice() call. None of them go to the ID3DXMesh that is actually being leaked. Through a bit of random checking, the ID3DXMesh mesh is actually lAllocID=146; which breaks where expected (on a D3DXLoadMeshFromX() call). Now, what I was wondering - anyone here tell me which bit it is that I'm forgetting/missing? I'm ready and waiting to be pointed and laughed at for being stupid [smile] Cheers, Jack

##### Share on other sites
Subordinate objects often AddRef their parent. e.g. IDirect3DDevice AddRef's IDirect3D - so failing to release the IDirect3DDevice would show two leaks - one in IDirect3D and one in IDirect3DDevice. IIRC the AllocId's are in order of creation, so the lower the Id, the earlier that interface was created.

##### Share on other sites
Quote:
 Original post by S1CASubordinate objects often AddRef their parent. e.g. IDirect3DDevice AddRef's IDirect3D - so failing to release the IDirect3DDevice would show two leaks - one in IDirect3D and one in IDirect3DDevice. IIRC the AllocId's are in order of creation, so the lower the Id, the earlier that interface was created.

Cheers for the reply... this pretty much confirms what I thought it was doing [smile]

However, I'm sure I remember a way of using that debug spew to actually identify the particular object that wasn't free'd.

That is, I managed to get it to break-point/identify the line where my ID3DXMesh was created, rather than just break-point on the parent/owner. I suppose it was always possible that I was using some of my own debugging code for this though.

Jack

##### Share on other sites
Actually, something else to bear in mind is that since the D3DX library is separate from the D3D runtime, its allocations won't show up in the AllocId's generated by the runtime.

If you're using a static library version of D3DX, the allocations it makes will be via "new", and so will show up as leaks in your code rather than leaks from the D3D runtime.

Am obvious complication with this is if a D3DX object AddRef's a D3D object - so without "traditional" leak tracking in your own app, you may also miss some D3DX leaks that have affected D3D objects.

##### Share on other sites
Quote:
 Original post by S1CAActually, something else to bear in mind is that since the D3DX library is separate from the D3D runtime, its allocations won't show up in the AllocId's generated by the runtime.

aaaah, the penny drops - makes perfect sense [smile]

It's probably a safe assumption that ID3DXMesh is creating an IDirect3DVertexBuffer9 and a IDirect3DIndexBuffer9 object internally. These not being freed would show up, but I don't strictly have any knowledge that they exist...

I guess it was some of my own code that managed to highlight the correct line of code previously.

Thanks for the replies - appreciated!
Jack

1. 1
2. 2
3. 3
4. 4
frob
15
5. 5

• 20
• 12
• 13
• 14
• 84
• ### Forum Statistics

• Total Topics
632143
• Total Posts
3004416

×