Jump to content
  • Advertisement
Sign in to follow this  
Bad Ham

Memory Leaks with std::wstring?

This topic is 4058 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

Hi everyone. I saw a post around that was talking about VC++'s methods of determining memory leaks (_CrtDumpMemoryLeaks()) and so I decided to run it on my basic input + window manager framework that I have going so far. Two of the memory leaks, I'm rather curious as to why they happened. Here's the function that causes the leak, the points with the leaks are marked with stars:
bool Win32Frame::initialize(bool windowed,
    const std::wstring& className,
    const std::wstring& winTitle,
    UINT winWidth, 
    UINT winHeight,
    HINSTANCE hInstance,
    LRESULT CALLBACK messageHandler(HWND, UINT, WPARAM, LPARAM))
{
  // If the class is already active then release it first
	if (isActive())	
		release();
  isWindowed_ = windowed;
	className_ = className; // *******
	windowTitle_ = winTitle; // ******
	
      // .........
}
And the method of calling it: Win32Frame WinClass; WinClass.initialize(true, TEXT("Class Name"), TEXT("Emblem Engine")); I'm not sure why this should cause a memory leak, as after all I can't just do "delete className_" in the destructor as it's not a pointer. Any ideas? [edit: Sanitized formatting - ApochPiQ] [Edited by - ApochPiQ on May 13, 2007 3:11:25 PM]

Share this post


Link to post
Share on other sites
Advertisement
The strings will appear leaked if your Win32Frame object is itself leaked, or if it is simply not destroyed until after you call _CrtDumpMemoryLeaks.

Share this post


Link to post
Share on other sites
I guess that would make sense, since WinClass is destroyed by scope at the end of WinMain, and _CrtDumpMemoryLeaks is called before that.

I tried the _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ) method to try to get the dump to happen after WinMain's scope, but I get nothing displayed...

Share this post


Link to post
Share on other sites
Are you sure your program is exiting cleanly, ie. no unhandled exceptions/stack overflows/anything of that nature? It's possible with some extreme failure cases that the leak check code isn't run. If something catastrophic happens during your program exit, it may look like it's shutting down fine, when in reality it's broken.

Another thing you can try is explicit scoping:

// Instead of this:
int main()
{
FooObject baz;
CheckForLeaks();
// baz goes out of scope here and cleans up too late to be seen, looks like a leak
}

// Do this:
int main()
{
{
FooObject baz;
// baz now goes out of scope here
}

CheckForLeaks();
// baz was already destructed, so it doesn't appear to leak
}

Share this post


Link to post
Share on other sites
That's an interesting way of doing it ApochPiQ, I tried it, which eliminated the two leaks within Win32Frame.

There are still two leaks left however, that seem to originate in xmemory (an internal header for the std library?)

This is the code:

template<class _Ty> inline
_Ty _FARQ *_Allocate(_SIZT _Count, _Ty _FARQ *)
{ // check for integer overflow
if (_Count <= 0)
_Count = 0;
else if (((_SIZT)(-1) / _Count) < sizeof (_Ty))
_THROW_NCEE(std::bad_alloc, NULL);

// allocate storage for _Count elements of type _Ty
return ((_Ty _FARQ *)::operator new(_Count * sizeof (_Ty))); //** This line
}


This one's really got me thrown off, this looks like some internal C++ workings to me. These are lines 35-45 in this file.

Share this post


Link to post
Share on other sites
Yep, that's the internal mechanism that takes care of actually allocating memory for STL classes.

Does the leak have a consistent allocation number? If so, try using _crtBreakAlloc to see what exact STL object is allocating the memory; from there it should be pretty easy to figure out why it's leaking.

Share this post


Link to post
Share on other sites
That's actually exactly how I've been getting to that line, in this case since my watch window doesn't seem to like those variables I've been using _CrtSetBreakAlloc() at the beginning of my program, and it always stops my at that line in the memory allocation mechanism. I can't step over/in/out from that point as there's no defined code after that point (and I'm not the greatest at assembly).

How would you suggest I use this to track down the leaking STL culprit?

Share this post


Link to post
Share on other sites
I've run into this before, with VC6's STL. Their STL implementation seems to use some sort of memory pool that isn't cleaned up until application cleanup, so when the string is destroyed, the memory is freed to the STL pool, and isn't actually deallocated until application shutdown.

If this is the same thing, then it's not a leak.

Share this post


Link to post
Share on other sites
I noticed this with STLport as well. Basically the strings maintain some kind of cached free list static thing that survives for the lifetime of the program. Because it relies on process termination to clean up, it shows up as a leak. (Which it sort of is, but it's more subtle than that.)

Remember, the problematic leaks are the ones which occur repeatedly over time. Forgetting to release some memory just before your program exits is not necessarily a huge problem.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!