How to determine source of IndexOutOfRangeException: Index 262080 is out of range of '10' Length.

Perhaps a silly question, but: Given you have quite a few systems, and this error (see spoiler) occurs – how do you find the source of the issue as fast as possible? It does not appear that I can determine this from the output I am given, or am I wrong?
Error Console Output


IndexOutOfRangeException: Index 262080 is out of range of '10' Length.
Unity.Collections.NativeSlice1[T].FailOutOfRangeError (System.Int32 index) (at /Users/builduser/buildslave/unity/build/Runtime/Export/NativeArray/NativeSlice.cs:222)
1[T].CheckReadIndex (System.Int32 index) (at /Users/builduser/buildslave/unity/build/Runtime/Export/NativeArray/NativeSlice.cs:174)
Unity.Collections.NativeSlice1[T].get_Item (System.Int32 index) (at /Users/builduser/buildslave/unity/build/Runtime/Export/NativeArray/NativeSlice.cs:199)
Unity.Physics.Broadphase+PrepareStaticBodyDataJob.ExecuteImpl (System.Int32 index, System.Single aabbMargin, Unity.Collections.NativeSlice
1[T] rigidBodies, Unity.Collections.NativeArray1[T] aabbs, Unity.Collections.NativeArray1[T] points, Unity.Collections.NativeArray1[T] filtersOut) (at Library/PackageCache/com.unity.physics@0.3.2-preview/Unity.Physics/Collision/World/Broadphase.cs:872)
Unity.Physics.Broadphase+PrepareStaticBodyDataJob.Execute (System.Int32 index) (at Library/PackageCache/com.unity.physics@0.3.2-preview/Unity.Physics/Collision/World/Broadphase.cs:866)
1[T].Execute (T& jobData, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at Library/PackageCache/


For me, this type of error usually occurred when Physics-related calls (Ray-/Collidercast) were made outside of the
Holy Physics Trinity




(combined with a Dependency = JobHandle.CombineDependencies(buildPhysicsWorld.FinalJobHandle, Dependency); at the start of OnUpdate).

We've been experiencing the same.
The fact that stuff like the BodyPairWriter works directly with unsafe ptrs and isn't catched by the safety systems make it even harder to debug since the application just crashes right away.
I haven't found a reliable way to find the source of this.

1 Like

Actually, this one may be a bug we recently discovered and it has already been fixed in the release coming in the following days. I can give you a fix to try out and let me know if it works for you!

In that method (Broadphase.ScheduleStaticTreeBuildJobs), there is a

var staticBodyDataJobHandle = new PrepareStaticBodyDataJob...

Replace that with

handle = new PrepareStaticBodyDataJob...

Also immediately below, instead of the JobHandle.CombineDependencies() call, just put handle = numStaticBodiesArray.Dispose(handle);

Let me know if that works and then we can discuss how to catch things like these!


Thank you! I'm also going to have to figure out how to replace package code again – 2020.1.0b10 resets the code to the Physics version selected in the package when switching back to Unity.

1 Like

Move required package to Packages folder (where manifest lies) from Library->PackagesCache and your package become local and wouldn't be overridden by the package manager



Thanks! We have been encountering this issue as well and it seems like the suggested change fixed the issue for us!

1 Like

@petarmHavok It appears to work for me as well. And yes, I'd be happy for pointers on how to figure out the source of future IndexOutOfRange exceptions.

Yea same here. I couldn't test that right away since the error just magically disappeared again.
So the problem was that numStaticBodiesArray got disposed when it was still used to Schedule the PrepareStaticBodyDataJob, did i understand that correctly?
Can we not add a ScheduleIndex0 which caches the safety handle or something similar?

Thanks for providing a fix, that bug made me go crazy.

1 Like

This particular one was a nightmare, we caught it accidentally, I'm very surprised we haven't seen it until now since it's been there forever. I have a slightly better fix for it in the pipeline, it may get to this release as well.

Now, in general, when getting these types of issues (Index random_large_number out of the range of 0-something_expected), I usually look at buffers not being allocated correctly. When I verify that's all good, I usually move towards scheduling issues where some code tries to access the buffer while it hasn't been allocated yet, or after it was deallocated. I know this is a bit vague, but it helps in most cases. For example, in this case, that is actually covered (buffer accessed after it was deallocated), but it was super hard to catch. Especially since we didn't have a repro in our samples, but got it from another project using the physics package.

In general, I feel like issues this complex don't usually pop up that often, so I'd say my guidance above would work in most cases.