Potential memory leak on rigid body create/destroy

[EightBitBanger]

Ive noticed increasing memory usage when creating and destroying rigid bodies over an extended period of time. I let this test run all night and found the programs memory usage will jump into the hundreds of megabytes by the next day and continue to gain if left running. I have overcome this issue by implementing a rigid body free list pool in my software to prevent de-allocation, however this does not necessarily address the issue within the physics engine. I just thought I would throw this out there as i dont think this issue has been raised. By the way, great engine! Keep up the good work.

Quick Update: After a bit of investigation I looked at the allocators in the physics world to see if anything looked out of place. The value in the variable mNbTimesAllocateMethodCalled in the physics world's heap allocator increases slowly as rigid body objects are created and destroyed. This tells me it could be a missing call to de-allocate. Ill post back if I find anything further.

[DanielChappuis]

Thanks for reporting this. I will try to investigate this. Do you have a small code example showing this leak (I mean when the mNbTimesAllocateMethodCalled increases after creating/destroying bodies) ?

[EightBitBanger]

This code example will reproduce the issue.

PhysicsCommon common;
PhysicsWorld* world = common.createPhysicsWorld();

MemoryManager& memMan = world->getMemoryManager();
HeapAllocator& allocator = memMan.getHeapAllocator();

while (true) {

    RigidBody* rigidBody = world->createRigidBody( Transform::identity() );

    world->destroyRigidBody( rigidBody );

    std::cout << allocator.mNbTimesAllocateMethodCalled << std::endl;

}

Im compiling to a dynamic library on windows 10 x64.

[DanielChappuis]

Hello. I am able to reproduce this issue on the 'master' branch but not on the 'develop' branch. Therefore, I think this issue is already fixed there. This will be available in the next release of the library.

[EightBitBanger]

Thank you for taking the time to look into this. I am glad to hear the issue was already resolved and i'm looking forward to the next release.