[ODE] Re: Memory leak from dBodySetPosition()?

[Geoff Carlton]

Trimesh has some static caches that need to be cleared.  Try adding a 
function in trimesh.cpp that is called during dCloseODE.

void dClearTrimeshCaches(void)
{
    dxTriMesh::defaultSphereCache.TouchedPrimitives.Empty();
    dxTriMesh::defaultBoxCache.TouchedPrimitives.Empty();
    dxTriMesh::defaultCCylinderCache.TouchedPrimitives.Empty();
    dxTriMesh::Faces.Empty();
}

I thought I submitted a patch for this, but it turns out I haven't.  
Assuming it fixes your allocations, its probably a good idea for this to 
go in the unstable branch.

Geoff


J. Perkins wrote:

>On 4/21/05, J. Perkins <starkos at gmail.com> wrote:
>  
>
>>I've got a straggler on my memory leak report that I am having a hard
>>time eradicating...
>>    
>>
>
>I realize my first post was pretty vague. I have managed to locate the
>allocation that is giving me trouble. It is in IceContainer.cpp at
>line 126:
>
>	// Get some bytes for new entries
>	udword*	NewEntries = new udword[mMaxNbEntries];
>
>Even after I have destroyed my ODE world, collision space, and all
>trimesh data, this allocation is still hanging around. It appears to
>belong to a Container that belongs to a SphereCollider that belongs to
>a trimesh. Everything looks like it should be cleaned up properly when
>the trimesh is destroyed; I am still investigating.
>
>The rest of my original post follows.
>
>Jason
>
>
>
>  
>
>>It only shows up when I call dBodySetPosition(). If
>>I go into that function in ode.cpp and comment out these three lines:
>>
>>    b->pos[0] = x;
>>    b->pos[1] = y;
>>    b->pos[2] = z;
>>
>>...the leak disappears. Clearly this simple assignment should not
>>cause any problems. Is this value being copied-on-change somewhere
>>else, perhaps? I've spent the last couple of hours browsing the code
>>but haven't been able to turn anything up.
>>
>>In case it matters, I'm running this on Windows under VS 2003 and the
>>leak report is generated by _CrtDumpMemoryLeaks() at program exit. The
>>size of the leak seems to vary between 8 and 32 bytes. The body in
>>question does not have a geom associated with it.
>>    
>>
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode
>
>
>
>  
>