(2023.2.x, 2023.1.x) IndexOutOfRangeException in Layout.LayoutManager.DestroyNode when changing UXML

[KamilCSPS]

Only in the player, no error in editor. Switching multiple times between UXMLs within a UIDocument via UIButtons will result in a IndexOutOfRangeException generated from the InputSystem.

Repeat between x3 / x10 times to generate error (appears random, clicking speed has no incidence). Application will become unresponsible afterwards. Reproduced 100% of times.

Reproduced in 2023.2.x, 2023.1.x. Could not reproduce in 2022.x (2022.2.19 &+ LTS).
Using Chrome Version 114.0.5735.199 (Official Build) (64-bit), Windows 10 Pro Version 10.0.19045 Build 19045.

Note: Randomly, sometimes the following error will appear instead of the IndexOutOfRangeException. InvalidOperationException: Failed to Free handle with Index=0 Version=0 at UnityEngine.UIElements.

Note(2): Also posted in InputSystem & UIToolkit forums as I don’t know which system is at fault.
https://forum.unity.com/threads/2023-2-x-2023-1-x-indexoutofrangeexception-in-layout-layoutmanager-destroynode-when-changing-uxml.1465175/#post-9171143

(2023.2.x, 2023.1.x) IndexOutOfRangeException in Layout.LayoutManager.DestroyNode when changing UXML

Only in a built WebGL player, no error in editor. Switching multiple times between UXMLs within a UIDocument via UIButtons will result in a IndexOutOfRangeException generated from the InputSystem. Repeat between x3 / x10 times to generate error (appears random, clicking speed has no incidence). Application will become unresponsible afterwards. Reproduced 100% of times. Reproduced in 2023.2.x, 2023.1.x. Could not reproduce in 2022.x (2022.2.19 &+ LTS). Using Chrome Version 114.0.5735.199 (Of…

Submitted bug report with repro project in Case: IN-49088

Unity IssueTracker - "IndexOutOfRangeException" in...

[unityruba]

Thanks for opening that bug report, @KamilCSPS

Do you happen to test if this occurs on native Windows builds at all?

[KamilCSPS]

@unityruba

Thanks for opening that bug report, @KamilCSPS

Do you happen to test if this occurs on native Windows builds at all?

I tried a windows standalone build and I can’t reproduce the error. Appears to only be happening when exporting to WebGL.

[KamilCSPS]

So we are approaching the 2 months mark and I see that the issue is under review.

@unityruba May I kindly ask to whom I should direct my questions (WebGL, Input, UITK) for follow-ups?

Thank you.

[jukka_j]

Sorry for the delay on this @KamilCSPS .

We had discussed this very issue with Ruba in a call just yesterday. The ticket went first through our incoming QA, and then since the issue was in “generic” UI code and seemingly not in our Web platform “low level” library code, we had requested a bisection to it to find the cause - which came back to a change that relates to code around UI element cleanup. So there has been active investigation going into it, but understandably not very active looking since none of that shows up on that issuetracker web site.

We don’t have a completely clear understanding yet of what is causing this specifically to happen for the Web platform, but we are looking into it. I hope you’ll bear with us a bit more on this.

[KamilCSPS]

@jukka_j

Sorry for the delay on this @KamilCSPS .

We had discussed this very issue with Ruba in a call just yesterday. The ticket went first through our incoming QA, and then since the issue was in “generic” UI code and seemingly not in our Web platform “low level” library code, we had requested a bisection to it to find the cause - which came back to a change that relates to code around UI element cleanup. So there has been active investigation going into it, but understandably not very active looking since none of that shows up on that issuetracker web site.

We don’t have a completely clear understanding yet of what is causing this specifically to happen for the Web platform, but we are looking into it. I hope you’ll bear with us a bit more on this.

Just as an FYI - Tested again in 2023.3.0a11 and it’s still happening. Really hoping to migrate our projects to the 2023.x branch when possible as there’s a lot of features we hope to leverage but this issue is a blocker.

[unityruba]

I’m sorry this took so long, but the issue turned out more complicated than we expected. There’s a team working on this that has 2 different code changes that hope will solve the problem. I will keep you updated once they test them out. I’ll also try out their fixes myself in the next couple of days.

[KamilCSPS]

FYI, for anyone else wondering on the status of this issue - here’s what I got from Unity support about workarounds and status last week:

“Unfortunately, no, nothing yet. The problem seems to be with the calls to the malloc/new directly. The fix will only be in 2023.3.“

I also did ask;

Can you confirm if the fix is in queue for the 2023.3 alpha or is it low-priority and may end up in 2023.3+ LTS (Unity 6?).

But have not received an answer.

[KamilCSPS]

Don’t know who at Unity works during the weekend but thank you!

[unityruba]

This was a fun one there was a lot of discussion around it, and thanks to Jukka and the IL2CPP team there’s a fix on the way.

[KamilCSPS]

@unityruba

This was a fun one there was a lot of discussion around it, and thanks to Jukka and the IL2CPP team there’s a fix on the way.

Thank you @jukka_j & @unityruba !

Any interesting insights you might be willing to share about it? You certainly picked my curiosity as to what kind of changes this bug required

[unityruba]

so the issue came down to the use of nested Finalizers, each of which made calls resizing a Stack backed by an Array, so there were calls to Array.Resize().

Array.Resize() is unaware/non-re-entrant, it does not know that while executing an Array.Resize() that mallocs, that the code might wind back in to again Array.Resize() the very same Array. This led to the Stack being in a bad state, which caused the error.

[manuelgoellnitz]

I can confirm that the bug is fixed!
We can finally update to 2023.