More news:
I added the following line before this happens:
And this is logged rather often, not just when crashing, which means that the cell spans array is oftentimes larger than the collider shapes array, thus resulting in plenty of bad accesses on the shapes array in the job (because it's a parallel for over cellSpans.count items)
I'm honestly not sure what these cell spans are, but if their number is supposed to be synchronized to the number of colliders, that's where I'd look. It appears as if there's a phyiscs frame (or so) of delay in the updates, because the message is only logged once and then it takes a bit until it's logged the next time (usually with different numbers)
I suppose because I'm removing colliders many times by disabling, the bad locations often still contain realistic information and thus it doesn't crash. Then maybe when I add plenty of colliders and the cell spans have been updated but the colliders haven't (for whatever reason), then of course the bad locations will contain garbage. This is only my guess, of course.
Code:
var identifyMoving = new IdentifyMovingColliders
{
movingColliders = movingColliders.AsParallelWriter(),
shapes = world.colliderShapes.AsNativeArray<BurstColliderShape>(cellSpans.count),
rigidbodies = world.rigidbodies.AsNativeArray<BurstRigidbody>(),
collisionMaterials = world.collisionMaterials.AsNativeArray<BurstCollisionMaterial>(),
bounds = world.colliderAabbs.AsNativeArray<BurstAabb>(cellSpans.count),
cellIndices = cellSpans.AsNativeArray<BurstCellSpan>(),
colliderCount = colliderCount,
dt = deltaTime
};
JobHandle movingHandle = identifyMoving.Schedule(cellSpans.count, 128);I added the following line before this happens:
Code:
if(cellSpans.count > world.colliderShapes.count) {
Debug.LogErrorFormat("BurstColliderWorld: cellSpans.count={0}, world.colliderShapes.count={1}",
cellSpans.count, world.colliderShapes.count);
}And this is logged rather often, not just when crashing, which means that the cell spans array is oftentimes larger than the collider shapes array, thus resulting in plenty of bad accesses on the shapes array in the job (because it's a parallel for over cellSpans.count items)
I'm honestly not sure what these cell spans are, but if their number is supposed to be synchronized to the number of colliders, that's where I'd look. It appears as if there's a phyiscs frame (or so) of delay in the updates, because the message is only logged once and then it takes a bit until it's logged the next time (usually with different numbers)
I suppose because I'm removing colliders many times by disabling, the bad locations often still contain realistic information and thus it doesn't crash. Then maybe when I add plenty of colliders and the cell spans have been updated but the colliders haven't (for whatever reason), then of course the bad locations will contain garbage. This is only my guess, of course.