Bug / Crash Invalid memory access using Burst backend

[pdinklag]

When colliders are disabled / removed, they're moved to the end of the colliders list. Then, colliderShapes.count is reduced, however cellSpans.count is not. This is the mechanism used to identify disabled colliders and remove them from the grid: being lists, the backing arrays for both cellSpans and colliderShapes still have the same size. IdentifyMoving colliders will access colliders past colliderShapes.count, and identify that they're disabled precisely because they're past the amount of cells (line 173 of BurstColliderWorld):

Right, my alarm should rather trigger if the cell spans count exceeded the collider shapes capacity rather than count, and indeed, that never happens. Thanks for the insight!

Would it be possible for me to take a look at your project, or at least get my hands on a simplified scene that reproduces the issue? This way I can join you more effectively on debugging.

I understand, and I wish I could reproduce this in a simplified scene. I tried to provoke this by deliberately disabling ObiColliders and adding new ones in the same frame, but so far, I never got these issues outside of my project. Just so you understand me as well here, it's an unreleased game that's announced to release late this year, that's why I'm reluctant to share the project. This problem has also awakened my ambition as an algorithm engineer now. 

---

In any event, I have a hypothesis now that could explain everything.
When a character is spawned, I create their ObiColliders and instantly disable them, because they start in a non-ragdoll state.

The materialIndex of a collider shape is only ever set by the corresponding shape tracker in UpdateIfNeeded, but that's never called for those colliders because they have been disabled. The shape struct that's left in the backing array will have its materialIndex still at zero. I added another field called "everUpdated" to ColliderShape (and also the Burst counterpart so there's no alignment issues), which is set to 1 when UpdateIfNeeded is called on a collider. It was also still at zero when the error occurred, which seems to confirm my theory.


I guess that a very certain order of enable/disable/create transactions has to occur so that the cellSpans count is incidentally so that these newly created and never updated colliders even get considered in the IdentifyMovingColliders job. That's probably why this is so hard to reproduce and why it hasn't happened to anybody yet. But I hope this seems plausible?

My use case may seem a bit strange, but it's actually what I want (I wish there was AddComponentDisabled in Unity...). IMO, the real issue here is that the materialIndex of a collider shape is (auto-)initialized as zero - a completely invalid value in my case where I don't use Obi collision materials - when it should be -1 to indicate "none (yet)". This can easily be fixed in ObiColliderHandle.CreateCollider. I just tried this and was unable to provoke the error again, so that may be the simple solution. I'll do a longer playtest in a build later.

Code:

colliderShapes.Add(new ColliderShape() { materialIndex = -1 });