Jump to content
  • Advertisement
Sign in to follow this  
SlimTimmy

ID3DXMesh causes memory leak

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm using the ID3DXMesh interface for the first time and came across a problem I don't have an explanation for. I instantiate a mesh object by calling the function D3DXCreateBox, afterwards I release it by using its Release member function. But the Direct3D runtime shows me at the end of the debug session that memory remained unreleased (I used the D3D_DEBUG_INFO preprocessor directive in order to gain this information) It says:
Quote:
Direct3D9: (INFO) :MemFini! Direct3D9: (ERROR) :Memory still allocated! Alloc count = 107 Direct3D9: (ERROR) :Current Process (pid) = 000004d0 Direct3D9: (ERROR) :Memory Address: 003254ac lAllocID=1 dwSize=000047f8, ReturnAddr=00db158b (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 0032bd44 lAllocID=10 dwSize=00001518, ReturnAddr=00da8154 (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 003232cc lAllocID=11 dwSize=00000018, ReturnAddr=00da8242 (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 0032d294 lAllocID=12 dwSize=000005e0, ReturnAddr=00da981f (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 0032331c lAllocID=13 dwSize=00000044, ReturnAddr=00db158b (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 00323034 lAllocID=14 dwSize=00000050, ReturnAddr=00db158b (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 00329f74 lAllocID=23 dwSize=000006bc, ReturnAddr=00dc2ffb (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 0032d8ac lAllocID=25 dwSize=000018e4, ReturnAddr=00db4ac9 (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 00323154 lAllocID=27 dwSize=00000018, ReturnAddr=00db4c0d (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 01080064 lAllocID=29 dwSize=00003508, ReturnAddr=00db158b (pid=000004d0) Direct3D9: (ERROR) :Memory Address: 0032f1c4 lAllocID=30 dwSize=00000198, ReturnAddr=00db158b (pid=000004d0) Direct3D9: (ERROR) :Total Memory Unfreed From Current Process = 47604 bytes
Instantiating more mesh objects does not change the amount of unfreed memory (47604 bytes) and therfore I guess that the D3DX library uses a certain block of memory (maybe a dynamic VB) which gets shared among the different meshes. Maybe the data gets freed later? Maybe it has something to do with the D3DX library sitting in a DLL now? Here is the source code of the test application (compile with D3D_DEBUG_INFO):
#include <windows.h>
#include <d3d9.h>
#include <d3dx9.h>

LPDIRECT3D9		g_pD3D       = 0;
LPDIRECT3DDEVICE9	g_pd3dDevice = 0;
ID3DXMesh		*g_pMesh = 0;

void initD3D( HWND hWnd )
{
	g_pD3D = Direct3DCreate9( D3D_SDK_VERSION );
     
	D3DPRESENT_PARAMETERS d3dpp; 
	ZeroMemory( &d3dpp, sizeof(d3dpp) );
	d3dpp.Windowed = TRUE;
	d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
	d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;

	g_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
                                      D3DCREATE_SOFTWARE_VERTEXPROCESSING,
                                      &d3dpp, &g_pd3dDevice );
	D3DXCreateBox(g_pd3dDevice, 1.0f, 1.0f, 1.0f, &g_pMesh, 0);
}

void cleanup()
{
	if(g_pMesh)
		g_pMesh->Release();
	if(g_pd3dDevice) 
		g_pd3dDevice->Release();
	if(g_pD3D)
		g_pD3D->Release();
}

void render()
{
	if( !g_pd3dDevice )
		return;
	g_pd3dDevice->Clear( 0, 0, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0,0,255), 1.0f, 0 );
   
	if( SUCCEEDED( g_pd3dDevice->BeginScene() ) )
        	g_pd3dDevice->EndScene();

	g_pd3dDevice->Present( 0, 0, 0, 0 );
}


LRESULT WINAPI MsgProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
	switch( msg )
	{
		case WM_DESTROY:
			cleanup();
			PostQuitMessage( 0 );
			return 0;

		case WM_PAINT:
			render();
			ValidateRect( hWnd, 0 );
			return 0;
	}

	return DefWindowProc( hWnd, msg, wParam, lParam );
}

INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR, INT )
{
	WNDCLASSEX wc = { sizeof(WNDCLASSEX), CS_CLASSDC, MsgProc, 0L, 0L, 
			  GetModuleHandle(0), 0, 0, 0, 0,
			  "DXClass", 0 };
	RegisterClassEx( &wc );
	
	HWND hWnd = CreateWindow( "DXClass", "ID3DXMesh causes memory leak", 
				  WS_OVERLAPPEDWINDOW, 100, 100, 300, 300,
				  GetDesktopWindow(), 0, wc.hInstance, 0 );

	initD3D(hWnd);
   
	ShowWindow( hWnd, SW_SHOWDEFAULT );
	UpdateWindow( hWnd );

	MSG msg; 
	while( GetMessage( &msg, NULL, 0, 0 ) )
	{
		TranslateMessage( &msg );
		DispatchMessage( &msg );
	}

	UnregisterClass( "DXClass", wc.hInstance );

	return 0;
}

Share this post


Link to post
Share on other sites
Advertisement
I think I have the same problem. It appeared why I updated my nvidia driver.
What's worse is that when I have the debug runtime selected I get an error in the device Reset function preventing the app from handling a lost device.

I tried isolating the allocs with a break on alloc but it's not performed by my code. I also tried to get more info with D3DSpy but when it hits the first leaked alloc is crashes. It seems to be a IDirect3DQuery9 objects allocated internally.

Share this post


Link to post
Share on other sites
Quote:
Original post by robert_p
you never called cleanup !


I do call it. ;)

case WM_DESTROY:
cleanup();
PostQuitMessage( 0 );
return 0;



Share this post


Link to post
Share on other sites
Release() will return the number of references remaining, so you might want to catch the return value and assert that it is zero within cleanup(). Could help you catch which objects have references still knocking around.

Share this post


Link to post
Share on other sites
(superbump)

I have a similarly low amount of memory (52K) allocated at the end of the run. The strange this is, if I do everything *except* render the meshes, I don't have the problem. I've verified that I've called Dispose on EVERY mesh that I FromStream or Clone. (the bummer is that when I Clone to change the vertex definition, I can't dispose the original until the app exits or it disposes something required for the cloned mesh).

I'm using Managed DirectX, have a Radeon 9800XT.


I'm going to ignore it because the leak size is completely independent of how many meshes I load or how many times I clone them, or render them, or how long I leave the app rendering.

Share this post


Link to post
Share on other sites
And which SDK version you have ? I'm have April 05 and haven't any problem with leaks (i use few simple and hierarchical meshes).

Share this post


Link to post
Share on other sites
Quote:
Original post by PetrCBR
And which SDK version you have ? I'm have April 05 and haven't any problem with leaks (i use few simple and hierarchical meshes).


I used the older february version. Today I downloaded the latest SDK (August) and it seems that the memory leak has been fixed!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!