• Advertisement
Sign in to follow this  

DXTrace memory leak

This topic is 2999 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 can not see any reason why this would be happening. I am using a macro from one of Frank Luna's books for error checking. EDIT: Any way to stop backslashes from concatenating lines in my posts?
#define HR(x) { HRESULT hr = x; if ( FAILED(x) ) { DXTrace( __FILE__, __LINE__, hr, _T(#x), true );}}
I also use smart pointers for COM objects, which I can only guess is relevant. On the Debug runtime, I get hit by a memory leak and slew of backtraces ONLY if this macro is used anywhere on lines involving one of my smart pointers or any COM object, for that matter.
// This is fine.
HRESULT hr = ( D3DXCreateTextureFromFile( m_pDev, _T(".\\data\\splash.jpg"), &m_Spl[1]  ) );

// Leak!
HR( D3DXCreateTextureFromFile( m_pDev, _T(".\\data\\splash.jpg"), &m_Spl[1]  ) );
Even if I expand the macro and type it right out, extra brackets included or not...
{
	HRESULT hr = D3DXCreateTextureFromFile( m_pDev, _T(".\\data\\credits.jpg"), &m_Spl[1]  );
	if ( FAILED(hr) ) 
	{
             // "Hello!" used since #hr not allowed
	     DXTrace( __FILE__, __LINE__, hr, _T("Hello!"), true );
	}
}
No leak. I have to toss formalities out the window and say: What the hell? I have gone around and tried this out on several lines and confirmed that if the HR macro is used, I get a leak. If I don't, I'm fine, even if I literally type the macro out. The code I have elsewhere is perfectly fine. The #x in the original definition can't be to blame if it's processed into a literal, can it?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by zyrolasting
I can not see any reason why this would be happening. I am using a macro from one of Frank Luna's books for error checking. EDIT: Any way to stop backslashes from concatenating lines in my posts?
*** Source Snippet Removed ***



You must have copied that macro wrong. The way you have it, if you use a function for the macro parameter (like D3DXCreateTextureFromFile) it will get called twice! This is because the macro will simply copy whatever you sent as the parameter twice, so for your example it will expand to this:

HRESULT hr = D3DXCreateTextureFromFile( m_pDev, _T(".\\data\\splash.jpg"), &m_Spl[1] );
if ( FAILED(D3DXCreateTextureFromFile( m_pDev, _T(".\\data\\splash.jpg"), &m_Spl[1] )) )
{
DXTrace( __FILE__, __LINE__, hr, _T("D3DXCreateTextureFromFile( m_pDev, _T(".\\data\\splash.jpg"), &m_Spl[1] )"), true );
}


For that macro to work you'd have to assign the HRESULT value to a local variable. But since you can't define a local variable in a macro (since it's not a function, you'll define the variable twice if you use it twice in the same block of code), you'd have define that local variable manually before using the macro somewhere and then write your macro like this:

#define HR(x) { hr = x; if ( FAILED(hr) ) { DXTrace( __FILE__, __LINE__, hr, _T(#x), true );}}


This is just one of the many ways that macros are evil.

Share this post


Link to post
Share on other sites
That IS evil. (I've seen the page, thanks) Thanks a lot for the clarification!
I know some code that about to get baleeted...

Share this post


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

  • Advertisement