crash in SpuFakeDma.cpp - what's wrong ?

[gjaegy]

Hi,

I am trying to get teh multithreaded dispatcher to work on a windows platform.

I have copied the code from the appMultithreadedDemo, however I get a reading access violation in cellDmaGet() at the following line:

Code: Select all

memcpy(localStore,mainMem,size);

Any idea what am I doing wrong ? I am using a btDbvtBroadphase, could this be the reason ?

[edit] after a second launch, I get a crash somewhere else (btconvexshape.cpp, line 271 - return this->localGetSupportingVertexWithoutMargin (localDir);).
Do I have to protect anything using mutex or whatever ?

Thanks
Greg

[gjaegy]

Some further information...

I use the ConvexBuilder (to decompose a mesh into a set of convex shapes) which generates a btCompoundShape.

Once the world is in place, durnig the first physic update step, I get an assert in "int getShapeTypeSize(int shapeType)", as the "shapeType" value is 1089017040.
This assert only happens on the 16th child (out of 22). When going up in the callstack, in spugatheringcollisiontask.cpp, in handleCollisionPair(), at the following lines:

Code: Select all

		int childShapeCount = spuCompoundShape->getNumChildShapes();

		for (int i = 0; i < childShapeCount; ++i)
		{
			btCompoundShapeChild& childShape = lsMem.compoundShapeData[0].gSubshapes[i];
			// Dma the child shape
			dmaCollisionShape (&lsMem.compoundShapeData[0].gSubshapeShape[i], (ppu_address_t)childShape.m_childShape, 1, childShape.m_childShapeType);

I have noticed that "lsMem.compoundShapeData[0].gSubshapes" only has 16 entries, and the loop is trying to access 22 children...

This appears to be a bug to me.

Any idea how I can fix it ?

[gjaegy]

Hmmm, good, I found my issue:

#define MAX_SPU_COMPOUND_SUBSHAPES 16

I understand there might be a reason for these arrays to have constant sizes, however it is very error-prone and could easily lead to some crash...

Couldn't these arrays be extendable (btAlignedArray) ?

For instance, there is no way to control how many child shapes are being created during the "ConvexBuilder" process (only the recursion depth can be), so I have no way to make sure the number of children is < MAX_SPU_COMPOUND_SUBSHAPES in any case...

So basically there is no way the software will not crash without controlling all data that could be virtually used. As the user might add his own data, the situation looks very dangerous to me..

Some assert() would help as well here in my opinion.

Or maybe I missed something ?


I have increased the value of MAX_SPU_COMPOUND_SUBSHAPES to 64 and recompiled. Now, my framerate is much lower (1 FPS now) so I started a quick profiling session.
Nearly 90% of the time is spent in ProcessConvexConcaveSpuCollision(), see the results below. One static mesh, one vehicle, 60 cinematic convex hull decomposition shapes.
I am not sure I am doing everything correctly. But I came to the conclusion that the multithreaded stuff is not usable yet...

[gjaegy]

*up*

[Erwin Coumans]

The SPU handling isn't optimized for btCompoundShape with many children. We should indeed have some better assert in place.

It is a known issue, and we'll make sure it gets solved:
http://code.google.com/p/bullet/issues/detail?id=310

For now, a quick workaround for the crash is to handle compound shapes on PPU (non-multi threaded): add some conditions for compound shape in supportsDispatchPairOnSpu method. See Bullet/src/BulletMultiThreaded/SpuGatheringCollisionDispatcher.cpp

Thanks for the report,
Erwin

[gjaegy]

Thanks for your answer and your support Erwin.

As my world mainly consists in one single static mesh and a lot of convex hull decomposition compound shapes, it seems I had better to use the standard non-multi-threaded dispatcher, right ?

Another question: is there also a performance issue when using compound shapes with many (around 20-25) children with the standard non-threaded dispatcher ?

Cheers,
Greg

[TomSpilman]

I'm running into this same issue for a different reason... it seems to crash on me if i have any compounds at all in my scene.

Poking around i found that in dmaCompoundShapeInfo() the spuCompoundShape pointer is garbage and we then get childShapeCount that is really big causing the crash.

I'm testing it further to make sure its not some other corruption in my application and if i can reproduce it in the demo application.