Jump to content
  • Advertisement
Sign in to follow this  
Raeldor

Memory leak problems

This topic is 4638 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 All, I am having trouble tracking some memory leaks. When I use the c runtime debugging dump I just get leaks on static objects (to be expect, I assume), but yet directx complains that there is still memory allocated (alloc count=141). Two questions. Is alloc count=141 the number of objects, or bytes? Also, is directx referring to it's own memory? I have releases on all my created objects. And why does directx complain during program exit and not when the device is release and com is un-initialized? Thanks for any help

Share this post


Link to post
Share on other sites
Advertisement
Hi,

Additional info. The result of this, is that I am getting an exception when the application exits. At this point the d3d interface and com have been released, yet it seems from the call stack that d3d8d.dll is getting called still and that is where the exception is happening.

Why would it get called after it has been shut down?

Share this post


Link to post
Share on other sites
More info... I have used the c runtime functions to check for memory leaks using _crtmemcheckpoint and _crtmemdifference at the start and end of my application, and there are no leaks.

So, where is directx getting its information from, and why am I getting an exception generated from it when my program exits, AFTER I have released the interfaces?

Share this post


Link to post
Share on other sites
Memory-leak trackers might incorrectly report leaks. If memory is allocated "pre main", it most likely is deallocated "post main" but potentially after the memory -leak tracker generates its report. For example, if you have a class-static data member which is an object that dynamically allocates memory, and if the destructor for this object is called *after* the memory-leak tracker generates its report, the tracker will report this as a leak. Both Developer Studio and DevPartner Studio (from Compuware) have this problem (memory-leak report generated before all "at exit" functions are called). One way around this is to have a function to create such objects and call the function *after* "main" has started. You also have a function to destroy these objects *before* "main" terminates. Between the create and destroy you have an application "run" function.

void main ()
{
CreateObjects();
RunApplication();
DestroyObjects();
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Wasting Time
Memory-leak trackers might incorrectly report leaks. If memory is allocated "pre main", it most likely is deallocated "post main" but potentially after the memory -leak tracker generates its report. For example, if you have a class-static data member which is an object that dynamically allocates memory, and if the destructor for this object is called *after* the memory-leak tracker generates its report, the tracker will report this as a leak. Both Developer Studio and DevPartner Studio (from Compuware) have this problem (memory-leak report generated before all "at exit" functions are called). One way around this is to have a function to create such objects and call the function *after* "main" has started. You also have a function to destroy these objects *before* "main" terminates. Between the create and destroy you have an application "run" function.

void main ()
{
CreateObjects();
RunApplication();
DestroyObjects();
}


Thanks, I definitely noticed this with static members in visual studio. The other way is to compare two checkpoints like...

// make snapshot
_CrtMemCheckpoint(&s1);

// put your code here

// check memory with snapshot
_CrtMemCheckpoint(&s2);
if (_CrtMemDifference(&s3, &s1, &s2))
_CrtMemDumpStatistics(&s3);

It won't give you the complete dump, but it will show you how many allocations were made between the two poins and not released.


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!