このサイトを正しく表示するには、最新のブラウザを使用し、Javascriptを有効化してください。

4.3 beta ArgumentOutOfRangeException

Dunull

Content:
Unity version: 6.4
Spine Unity Runtime version: 4.3.72

An occasional exception occurs when destroying a character at runtime:

ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index System.Collections.Generic.List1[T].get_Item (System.Int32 index)
Spine.Unity.SkeletonUpdateSystem.MainThreadAfterUpdate (System.Collections.Generic.List1[T] skeletons, System.Int32 skeletonEnd) (at SkeletonUpdateSystem.cs:529) Spine.Unity.SkeletonUpdateSystem.UpdateAsync (System.Collections.Generic.List1[T] skeletons, Spine.Unity.UpdateTiming updateTiming) (at SkeletonUpdateSystem.cs:370)
Spine.Unity.SkeletonUpdateSystem.Update () (at SkeletonUpdateSystem.cs:288)`

Spinebot

I understand you're encountering an ArgumentOutOfRangeException when destroying characters at runtime with the spine-unity 4.3 beta. This appears to be a concurrency issue in the SkeletonUpdateSystem where a skeleton is being removed from the update list while the system is iterating over it.

Potential Causes

This exception typically occurs when:

A skeleton is destroyed during the update cycle
The skeleton list is modified while being iterated
There's a timing issue between skeleton destruction and the update system's internal state

Recommended Steps

Update to the latest 4.3 beta build - Since you're using 4.3.72, check if a newer beta build is available at https://esotericsoftware.com/spine-unity-download. This type of threading/timing issue may have been fixed in a more recent build.

Verify proper destruction - Ensure you're destroying skeletons properly:

   // Proper way to destroy
   Destroy(skeletonGameObject);
   
   // Not allowed with threaded skeleton game objects:
   // DestroyImmediate(skeletonGameObject);

Avoid destroying during update callbacks - If you're destroying skeletons within UpdateComplete, UpdateLocal, or other skeleton update callbacks, try deferring the destruction:

   void AfterUpdateComplete(ISkeletonAnimation anim) {
       // Don't destroy here directly
       StartCoroutine(DestroyNextFrame(anim.gameObject));
   }
   
   IEnumerator DestroyNextFrame(GameObject go) {
       yield return null;
       Destroy(go);
   }

Report the issue - If updating doesn't resolve the problem, this may be a bug in the beta. Consider reporting it with:
- Your exact reproduction steps
- The specific scenario when it occurs (e.g., destroying multiple skeletons at once, destroying during certain animations, etc.)
- Whether it's consistent or intermittent

Since this is a beta version, such issues are expected and the development team would appreciate detailed bug reports to improve stability before the final release.

Harald

@Dunull Spinebot was too lenient with mentioning DestroyImmediate();. With only very few exceptions, this is in general only allowed in Editor scripting code outside play mode, not inside the game loop while the game is running. Are you using DestroyImmediate()?

Dunull

Harald I did not use DestroyImmediate(). I only used gameObject.SetActive(false).

Harald

Dunull Thanks for clarifying, when you mentioned "destroying a character at runtime" I didn't think of deactivating the GameObject but a Destroy variant.

From where are you calling gameObject.SetActive(false)?

Dunull

Harald
The issue happened because I called gameObject.SetActive(false) directly inside a Spine animation event callback. In my case, the Spine character has a child Skeleton GameObject, and I attempted to hide that child object inside OnSpineEvent.

Minimal code that caused the error:

void OnSpineEvent(TrackEntry entry, Spine.Event e) {
    if (e.Data.Name == "hide_event") {
        // Hiding a child Skeleton GameObject during the callback
        childSkeletonGameObject.SetActive(false);
    }
}

(The fix is simply using a boolean flag here and deferring the SetActive(false) to Unity's Update() method.)

I found the culprit by adding a stack trace check inside SkeletonUpdateSystem.UnregisterFromUpdate:

public void UnregisterFromUpdate (UpdateTiming updateTiming, SkeletonAnimationBase skeletonAnimation) {
    // ... [Original Spine Code] ...
    skeletonAnimations.Remove(skeletonAnimation);
    skeletonAnimation.IsUpdatedExternally = false;

    // ======== [My Debug Trap] ========
    var trace = UnityEngine.StackTraceUtility.ExtractStackTrace();
    if (trace.Contains("UpdateAsync") || trace.Contains("UpdateInternalSplit") || trace.Contains("UpdateExternal")) {
        UnityEngine.Debug.LogError($"GameObject '{skeletonAnimation.gameObject.name}' removed itself mid-update, causing the list to crash!\nStackTrace:\n{trace}");
    }
    // =================================
}

Apologies, this turned out to be an issue in my own code. Thanks for your help!

Harald

@Dunull Thanks for taking the time to post the additional details, and what fixes the issue! I suspected something like this, and could reproduce it with another callback, just wanted to be sure I'm not missing additional scenarios.

Apologies, this turned out to be an issue in my own code. Thanks for your help!

No need to apologize, thanks very much for reporting! So far we haven't defined calling SetActive(false) as an illegal action inside of callbacks when using threaded animation or mesh generation, so we'll see if we can automatically defer any unregistration on our side, so you don't have to modify your code which worked beforehand.

What we unfortunately can't prevent is that the behaviour might slightly change compared to without threading, as the GameObject might then receive one more update in the same frame. This lies in the nature of parallelizing skeleton updates in general however, and I see little that we can do about it without overcomplicating things.

Harald

@Dunull We've just implemented a fix for the issue which automatically defers modifying the skeleton list to after it is processed, so you can call SetActive(false) or SetActive(true) even repeatedly from event callbacks and still get the correct outcome.

A new spine-unity 4.3-beta untypackage is available:
https://esotericsoftware.com/spine-unity-download

Issue ticket for later reference:
EsotericSoftware/spine-runtimes3078

Dunull

Harald Thanks a lot for the fix!

Harald

@Dunull No problem at all, thanks very much for reporting!