I’m on WebGL and using Addressables to load uxml files.
I’m loading and instatiating one element 6 times and the first time I get the following error, but the other 5 times it works fine:
InvalidOperationException: Failed to Free handle with Index=0 Version=0
at UnityEngine.UIElements.Layout.LayoutDataStore.Free (UnityEngine.UIElements.Layout.LayoutHandle& handle) [0x00000] in <00000000000000000000000000000000>:0
What’s interesting is that it was working fine before and I’ve been reverting back and forth the changes when this started happing, but there’s no pattern.
I was close to identify the issue, but without any luck:
Maybe it was using Addressable Asset Settings - Catalog - Player Version Override (I switched back and fourth, it was fixed at some point, but the issue came back)
Maybe because intially the VisualElement - display is none (so hidden) and mayb the Layout issue, thought it doesn’t seem to be, since the other elements work fine.
Still can’t identify it. Do you mind sharing if you managed to resolve it?
I can’t reproduce in Unity 2022.x LTS. Can easily reproduce in 2023.1.x and 2023.2.x.
Will share a bug report if there’s no follow up later this week.
I have the same issue but I don’t really need a webgl build right now so I didn’t investigate much and I didn’t submit a bug report.
EDIT: I don’t use Addressables to load uxml files, I use Resources.Load (not sure if it’s different)
There seems to be a serious bug somewhere, when creating VisualElements during runtime.
Sometimes it works fine, sometimes I get errors like
IndexOutOfRangeException: Index was outside the bounds of the array.
at System.Collections.Generic.Stack`1[T].PushWithResize (T item) [0x00000] in <00000000000000000000000000000000>:0
at System.Collections.Generic.Stack`1[T].Push (T item) [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.UIElements.Layout.LayoutManager.DestroyNode (UnityEngine.UIElements.Layout.LayoutNode& node) [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.UIElements.VisualElement.Finalize () [0x00000] in <00000000000000000000000000000000>:0
and this:
System.InvalidOperationException: Failed to Free handle with Index=0 Version=0
at UnityEngine.UIElements.Layout.LayoutDataStore.Free (UnityEngine.UIElements.Layout.LayoutHandle& handle) [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.UIElements.Layout.LayoutManager.FreeNode (UnityEngine.UIElements.Layout.LayoutHandle handle) [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.UIElements.Layout.LayoutManager.TryFreeNodes () [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.UIElements.Layout.LayoutManager.CreateNodeInternal (UnityEngine.UIElements.Layout.LayoutHandle configHandle) [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.UIElements.Layout.LayoutManager.CreateNode () [0x00000] in <00000000000000000000000000000000>:0
And different browsers have different results:
Often Chrome and Edge work fine, but Firefox throws those exceptions every time.
And sometime when I open the browser and start the app everything works fine. Then I reload the page and the error occurs.
Today I tried something new:
Since It seems to be memory related I switched in the player publishing settings from “full stacktrace” to “Exceptions only”.
Then I get no errors in Firefox but in Chrome and Edge the whole app crashes with a javascript error popup:
vishow_1_22_3_a.framework.js:9 System.InvalidOperationException: Stack empty.
at System.Collections.Generic.Stack`1[T].ThrowForEmptyStack () [0x00000] in <00000000000000000000000000000000>:0
I don’t know if it is the same bug (but i voted anyway).
When I compare code code of 2022.3. with 2023.2.1 there are significant changes in the memory handling of ui elements. I don’t know when those where added.
I’ve been dealing with the same problem for a few days. I think the problem is caused by the LayoutManager.TryFreeNodes() method. I was getting the error on the line VisualElement choiceElement = new VisualElement(); .
As far as I understand, webgl gets a Timeout error from threading because it runs slower than the editor.
As a temporary solution, I caught the error with Try-catch and called the method again with the same parameters in the catch, and it is now working despite receiving an error.