[ODE] apparent memory leaks

[David McClurg]

Nate's patch worked for me.  No more leaks.  If you use CVS, put this function at the bottom of geom.cpp and call it before exit.

void dCloseODE() 
{
	if (colliders)
	{
		delete colliders;
		colliders = 0;
	}
	if (classes)
	{
		for (int i = 0; i < classes->size (); i++)
		{
			dFree ((*classes)[i], sizeof (dxGeomClass));
		}
		delete classes;
		classes = 0;
	} 
}

-----Original Message-----
From: Si Brown [mailto:si_br0wn@hotmail.com]
Sent: Saturday, 15 June 2002 4:31 AM
To: ode@q12.org
Subject: RE: [ODE] apparent memory leaks



Oops I should make sure I'm talking about the right thing before hitting the 
send button (i.e. geometry class objects vs geometry objects).

It's worth mentioning though that the singletons still aren't freed by ODE 
when the app exits, and in a debug build are just flagged by the debug 
allocator so that the used memory is not reported by ODE when the app exits.

Ta,
Si (hopefully talking on-topic now)

>From: Nate W <coding@natew.com>
>To: ode@q12.org
>Subject: RE: [ODE] apparent memory leaks
>Date: Fri, 14 Jun 2002 03:11:11 -0700 (PDT)
>
>On Fri, 14 Jun 2002, Si Brown wrote:
>
> > >also, i have some memory leaks.  for example, dSphereClass never gets
> > >freed.  i don't see anywhere in ode that takes care of freeing
> > >dSphereClass.  Am I missing something?
>
>I ran into the same thing, using MSVC's _CrtDumpMemoryLeaks to detect
>leakage.  Are you using VC.Net?
>
>Anyhow... In ODE .025, the geometry class singletons were not freed, but
>it's not a problem because they're singletons (only one of each will ever
>be allocated) and the OS wipes the entire heap when the process
>terminates.  So it's nothing to worry about.  I still prefer a clean
>memory leak dump when my app closes, though.  It beats having to scan a
>list of a half-dozen "leaks" and make sure there isn't an extra leak or
>two due to something wrong in my application code.  So I wrote some code
>to explicitly free the singletons.
>
>My recall is pretty fuzzy here, as I haven't dealt with this since
>upgrading to .030, but... I think Russ put some cleanup code in .030 but
>now there's a timing issue - your app is probably calling
>_CrtDumpMemoryLeaks before ODE cleans up the singletons.  I couldn't find
>a way to resolve that timing issue because MFC calls _CrtDumpMemoryLeaks
>from deep inside itself... so, I put the explicit-cleanup function back
>into my ODE DLL and now I'm getting perfect memory leak reports again.
>
>Here's the function, just invoke it somewhere in your app's shutdown code.
>In my case it's called during CMyApp::~CMyApp, and that works fine:
>
>void __declspec (dllexport)  dCloseODE ()
>{
>	if (colliders)
>	{
>		dFree (colliders->_data, sizeof (dColliderEntry) * classes->_anum);
>		dFree (colliders, sizeof(dArrayBase));
>		colliders = 0;
>	}
>	if (classes)
>	{
>		for (int i = 0; i < classes->size (); i++)
>		{
>			dFree ((*classes)[i], sizeof (dxGeomClass));
>		}
>		dFree (classes->_data, sizeof (dxGeomClass*) * classes->_anum);
>		dFree (classes, sizeof(dArrayBase));
>		classes = 0;
>	}
>}
>
>
>Nate Waddoups
>Redmond WA USA
>http://www.natew.com
>