Sign in to follow this  

Memory leak problems

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

This topic is 4353 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this