Bullet 2.58 Crash and pool problems.

[DevO]

First thanks for the new Bullet 2.58!!!


Unfortunately it does crash in some cases!

First problem is with btPoolAllocator and this assert
btAssert((unsigned char*)ptr >= m_pool && (unsigned char*)ptr < m_pool + m_maxElements * m_elemSize);

Second is in btSequentialImpulseConstraintSolver::solveGroupCacheFriendly()

Code: Select all

				
int numPoolConstraints = tmpSolverConstraintPoolSize;
for (j=0;j<numPoolConstraints;j++)
{
	btSolverConstraint& solveManifold = tmpSolverConstraintPool[gOrderTmpConstraintPool[j]];
        resolveSingleCollisionCombinedCacheFriendly(tmpSolverBodyPool[solveManifold.m_solverBodyIdA],
							tmpSolverBodyPool[solveManifold.m_solverBodyIdB],solveManifold,info);
}

Some times solveManifold.m_solverBodyIdA and solveManifold.m_solverBodyIdB are big negative values like -1576945456 and then Bullet will crash.

If you go tough all values from tmpSolverConstraintPoolSize[] array then [0] , [5], [10], [15]... contains this negative values.

This happens only with big scenes so this must be probably problem with btStackAlloc or btPoolAllocator...

[Erwin Coumans]

If the allocated memory is not enough, it will assert (in debug mode) or crash in release mode.

Can you try to increase the default pool sizes?
For a future version, I'm thinking of having some mechanism to deal with out-of-memory situations (callback/second 'heap' memory allocator)

Code: Select all

btDefaultCollisionConfiguration* collisionConfiguration = new btDefaultCollisionConfiguration();
int maximumStackSize = 10*1024*1024;// //10Mb
collisionConfiguration->setStackAllocatorSize(maximumStackSize);
int maximumOverlappingPairs = 128*1024;//tweak this value
collisionConfiguration->setPersistentManifoldPoolSize( maximumOverlappingPairs);
collisionConfiguration->setCollisionAlgorithmPoolSize( maximumOverlappingPairs);

The second crash (in the constraint solver), is there no assert involved?

Hope this helps,
Erwin

[DevO]

I have now replaced btSequentialImpulseConstraintSolver::solveGroupCacheFriendly() function with old one from 2.56 and it work as well!!!

Increasing memory seems to NOT help.

One problem that I have found now is that btPoolAllocator created in
btCollisionDispatcher::btCollisionDispatcher() will never deleted and btPoolAllocator does not have any destructor!

The problem with btPoolAllocator::free is this
if( (unsigned char*)ptr < m_pool)

Some times ptr address is below m_pool address.

P.S.: All my test are done on Win64 bit!

EDIT:

Adding this solves problem with memory leak but not with other problems!

Code: Select all

~btPoolAllocator() 
{
	delete m_pool;
}
btCollisionDispatcher::~btCollisionDispatcher()
{
	delete m_collisionAlgorithmPoolAllocator;
	delete m_persistentManifoldPoolAllocator;
}

[ola]

Hi,

I'm also having that crash in btSequentialImpulseConstraintSolver::solveGroupCacheFriendly() now. I thought I had introduced some nasty bug in my own code myself, so I'm actually somewhat happy to see this thread

In my case, I have a segmentation fault after about 1-2 seconds of simulation, having imported the jenga.dae collada file into my game engine/world (plenty of rigid bodies and a pretty huge world, using double precision).

The crash is caused by an assert it seems, at least following the ddd debugger on Linux, on this line in ./src/BulletDynamics/Dynamics/btRigidBody.h:226

Code: Select all

        inline void setLinearVelocity(const btVector3& lin_vel)
        { 
   ====>>    assert (m_collisionFlags != btCollisionObject::CF_STATIC_OBJECT);
                m_linearVelocity = lin_vel; 
        }

Here's the stack:

Code: Select all

#1  0x082659b3 in btSolverBody::writebackVelocity (this=0xad65c0f0) at src/BulletDynamics/ConstraintSolver/btSolverBody.h:53
#2  0x08263efb in btSequentialImpulseConstraintSolver::solveGroupCacheFriendly (this=0x89fa808, bodies=0xc49edd0, numBodies=1, manifoldPtr=0xc4b6360, numManifolds=2, constraints=0x0, numConstraints=0, infoGlobal=@0x89fa99c, debugDrawer=0x0, stackAlloc=0x89f03d0, dispatcher=0x89f9cf0) at src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp:807
#3  0x08261f08 in btSequentialImpulseConstraintSolver::solveGroup (this=0x89fa808, bodies=0xc49edd0, numBodies=1, manifoldPtr=0xc4b6360, numManifolds=2, constraints=0x0, numConstraints=0, infoGlobal=@0x89fa99c, debugDrawer=0x0, stackAlloc=0x89f03d0, dispatcher=0x89f9cf0) at src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp:829
#4  0x0826e848 in ProcessIsland (this=0xbfe4975c, bodies=0xc49edd0, numBodies=1, manifolds=0xc4b6360, numManifolds=2, islandId=67) at src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:513
#5  0x082838e9 in btSimulationIslandManager::buildAndProcessIslands (this=0x89faa00, dispatcher=0x89f9cf0, collisionObjects=@0x89fa904, callback=0xbfe4975c) at src/BulletCollision/CollisionDispatch/btSimulationIslandManager.cpp:345
#6  0x08271bb3 in btDiscreteDynamicsWorld::solveConstraints (this=0x89fa900, solverInfo=@0x89fa99c) at src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:542
#7  0x08271cda in btDiscreteDynamicsWorld::internalSingleStepSimulation (this=0x89fa900, timeStep=0.016666666666666666) at src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:276
#8  0x08272f0d in btDiscreteDynamicsWorld::stepSimulation (this=0x89fa900, timeStep=0.095688104629516602, maxSubSteps=10, fixedTimeStep=0.016666666666666666) at src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp:237

I've tried using the new bt32BitAxisSweep3 as well as the btSimpleBroadphase.

Let me know if I can assist with anything.

Best regards,
Ola

[Erwin Coumans]

First problem is with btPoolAllocator and this assert
btAssert((unsigned char*)ptr >= m_pool && (unsigned char*)ptr < m_pool + m_maxElements * m_elemSize);

Can you please provide the full callstack for this assert?

I will incorporate your fixes for the destructor/memory deallocation, and revert the constraint solver to previous version, until the problems are fixed.
Thanks,
Erwin

[DevO]

First problem is with btPoolAllocator and this assert
btAssert((unsigned char*)ptr >= m_pool && (unsigned char*)ptr < m_pool + m_maxElements * m_elemSize);

Can you please provide the full callstack for this assert?

Here is the full callback of btPoolAllocator problem.

Code: Select all

btPoolAllocator::free(void * ptr=0x000000000bcfa6e0)  Line 80
btCollisionDispatcher::freeCollisionAlgorithm(void * ptr=0x000000000bcfa6e0)  Line 311
btOverlappingPairCache::cleanOverlappingPair(btBroadphasePair & pair={...}, btDispatcher * dispatcher=0x000000000447a510)  Line 63
btAxisSweep3Internal<unsigned int>::calculateOverlappingPairs(btDispatcher * dispatcher=0x000000000447a510)  Line 500
btCollisionWorld::performDiscreteCollisionDetection()  Line 146
btDiscreteDynamicsWorld::internalSingleStepSimulation(float timeStep=0.016666668) Line 272

After changing the code to this it does not crash any more but the problem is still there .

Code: Select all

	void	free(void* ptr)
	{
		 if (ptr) {
			if( (unsigned char*)ptr < m_pool)  return; //Problem !!!
			if( (unsigned char*)ptr >= m_pool + (m_maxElements * m_elemSize) )return;
                btAssert((unsigned char*)ptr >= m_pool && (unsigned char*)ptr < m_pool + m_maxElements * m_elemSize);

                *(void**)ptr = m_firstFree;
                m_firstFree = ptr;
                 ++m_freeCount;
            }
	}

This problem seems to occur much often if GIMPACT meshes are colliding.



I am using bt32BitAxisSweep3 with this change now!

Code: Select all

bt32BitAxisSweep3::bt32BitAxisSweep3(const btPoint3& worldAabbMin,const btPoint3& worldAabbMax, unsigned int maxHandles , btOverlappingPairCache* pairCache )
//:btAxisSweep3Internal<unsigned int>(worldAabbMin,worldAabbMax,0xfffffffe,0x7fffffff,maxHandles,pairCache)
:btAxisSweep3Internal<unsigned int>(worldAabbMin,worldAabbMax,0xeffffffe,0xefffffff,maxHandles,pairCache)//10.09.2007

regards,
DevO

[Erwin Coumans]

Are you using GIMPACT provided with Bullet 2.58, or a modified version?

Can you verify that btGImpactCollisionAlgorithm (btGImpactCollisionAlgorithm.h) is allocated using the pool allocator, like this:

Code: Select all

struct CreateFunc :public 	btCollisionAlgorithmCreateFunc
	{
		virtual	btCollisionAlgorithm* CreateCollisionAlgorithm(btCollisionAlgorithmConstructionInfo& ci, btCollisionObject* body0,btCollisionObject* body1)
		{
			void* mem = ci.m_dispatcher1->allocateCollisionAlgorithm(sizeof(btGImpactCollisionAlgorithm));
			return new(mem) btGImpactCollisionAlgorithm(ci,body0,body1);
		}
	};

After changing the code to this it does not crash any more but the problem is still there .

Which problem is still there apart from the crash?

I am using bt32BitAxisSweep3 with this change now!

Code: Select all

bt32BitAxisSweep3::bt32BitAxisSweep3(const btPoint3& worldAabbMin,const btPoint3& worldAabbMax, unsigned int maxHandles , btOverlappingPairCache* pairCache )
//:btAxisSweep3Internal<unsigned int>(worldAabbMin,worldAabbMax,0xfffffffe,0x7fffffff,maxHandles,pairCache)
:btAxisSweep3Internal<unsigned int>(worldAabbMin,worldAabbMax,0xeffffffe,0xefffffff,maxHandles,pairCache)//10.09.2007

Why did you need to change the mask/sentinel exactly?

Thanks for the feedback, it is very helpful,
Erwin

[DevO]

Thanks this solve the problem with btPoolAllocator!
I was using GIMPACT 0.1 with old allocator.

Why did you need to change the mask/sentinel exactly?

This was another problem with 32bit version of AxisSweep3 and ground plane with maximum size.
After quantization the integer values are wrong and there was no collision with the plane.


Thanks for you help!

[Erwin Coumans]

Bullet 2.59 is uploaded: the constraint solver has been reverted, and the fixes for the memory pool applied, and an issue related to kinematic objects is fixed.

The broadphase sentinel/mask fix will be tested and applied for next release.
Thanks!
Erwin

[DevO]

Thanks!!!
Now it seems to work well!

Capsule seems to work too for me, but it is a bit modified.

regards,
DevO

[Erwin Coumans]

Can you confirm that the unmodified btCapsuleShape of Bullet 2.59 works fine, for Y-up capsules?

It seems you just added functionality for X and Z axis, this is not a bug-fix, right?

Thanks,
Erwin