Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

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

Discussion in 'Physics for ECS' started by florianhanke, Jun 13, 2020.

  1. florianhanke

    florianhanke

    Joined:
    Jun 8, 2018
    Posts:
    426
    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?
    IndexOutOfRangeException: Index 262080 is out of range of '10' Length.
    Unity.Collections.NativeSlice`1[T].FailOutOfRangeError (System.Int32 index) (at /Users/builduser/buildslave/unity/build/Runtime/Export/NativeArray/NativeSlice.cs:222)
    Unity.Collections.NativeSlice`1[T].CheckReadIndex (System.Int32 index) (at /Users/builduser/buildslave/unity/build/Runtime/Export/NativeArray/NativeSlice.cs:174)
    Unity.Collections.NativeSlice`1[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.NativeArray`1[T] aabbs, Unity.Collections.NativeArray`1[T] points, Unity.Collections.NativeArray`1[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)
    Unity.Jobs.IJobParallelForDeferExtensions+JobParallelForDeferProducer`1[T].Execute (T& jobData, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at Library/PackageCache/com.unity.jobs@0.2.10-preview.11/Unity.Jobs/IJobParallelForDefer.cs:58)

    For me, this type of error usually occurred when Physics-related calls (Ray-/Collidercast) were made outside of the
    Code (CSharp):
    1. [UpdateAfter(typeof(BuildPhysicsWorld))]
    2. [UpdateInGroup(typeof(ServerSimulationSystemGroup))]
    3. [UpdateAfter(typeof(StepPhysicsWorld))]
    (combined with a
    Dependency = JobHandle.CombineDependencies(buildPhysicsWorld.FinalJobHandle, Dependency);
    at the start of
    OnUpdate
    ).
     
  2. Lukas_Kastern

    Lukas_Kastern

    Joined:
    Aug 31, 2018
    Posts:
    97
    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.
     
    florianhanke likes this.
  3. petarmHavok

    petarmHavok

    Joined:
    Nov 20, 2018
    Posts:
    461
    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!
     
    Lukas_Kastern and florianhanke like this.
  4. florianhanke

    florianhanke

    Joined:
    Jun 8, 2018
    Posts:
    426
    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.
     
    petarmHavok likes this.
  5. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,683
    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
     
    steveeHavok and florianhanke like this.
  6. florianhanke

    florianhanke

    Joined:
    Jun 8, 2018
    Posts:
    426
    Thanks!
     
  7. Zec_

    Zec_

    Joined:
    Feb 9, 2017
    Posts:
    148
    Thanks! We have been encountering this issue as well and it seems like the suggested change fixed the issue for us!
     
    petarmHavok likes this.
  8. florianhanke

    florianhanke

    Joined:
    Jun 8, 2018
    Posts:
    426
    @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.
     
  9. Lukas_Kastern

    Lukas_Kastern

    Joined:
    Aug 31, 2018
    Posts:
    97
    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.
     
    petarmHavok likes this.
  10. petarmHavok

    petarmHavok

    Joined:
    Nov 20, 2018
    Posts:
    461
    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.
     
    Zeffi, thelebaron, Sima_Havok and 2 others like this.