Errors in Built Application in CurvySplineSegment

[TdayMFG]

The forum 404s if I try and make a post with the stack traces relevant to this issue for some reason. I'll see if I can put them in a reply.

In Windows & MacOS builds in unity 6.0.43f1 I get index out of range and null ref exceptions within a curvy generator hierarchy. These same setups work just fine in editor.

---

I don't understand why the forum keeps freaking out when I try and paste the stack traces in directly (just hangs when trying to post or edit a message). Here is a link to a pastebin with the stack traces

https://pastebin.com/TVmGpRKy

The errors are within CurvySplineSegment.GetOrientationUpFast (IndexOutofRangeException) and a NullReferenceException in CurvySplineSegment.get_HasUnprocessedLocalPosition.

EDIT: Adding stack traces in after forum issue has been fixed

NullReferenceException: Object reference not set to an instance of an object.
at UnityEngine.Bindings.ThrowHelper.ThrowNullReferenceException (System.Object obj) [0x00000] in <00000000000000000000000000000000>:0
at UnityEngine.Transform.get_localPosition () [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.CurvySplineSegment.get_HasUnprocessedLocalPosition () [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.CurvySpline.DoUpdate () [0x00000] in <00000000000000000000000000000000>:0

IndexOutOfRangeException: Index was outside the bounds of the array.
at FluffyUnderware.Curvy.CurvySplineSegment.GetOrientationUpFast (System.Single localF, UnityEngine.Space space) [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.SplineInputModuleBase.GetSplineData (FluffyUnderware.Curvy.CurvySpline spline, System.Boolean fullPath, FluffyUnderware.Curvy.Generator.CGDataRequestRasterization raster, FluffyUnderware.Curvy.Generator.CGDataRequestMetaCGOptions options) [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.Modules.InputSplinePath.OnSlotDataRequest (FluffyUnderware.Curvy.Generator.CGModuleInputSlot requestedBy, FluffyUnderware.Curvy.Generator.CGModuleOutputSlot requestedSlot, FluffyUnderware.Curvy.Generator.CGDataRequestParameter[] requests) [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.CGModuleInputSlot.GetData[T] (System.Int32 slotIndex, System.Boolean& isDataDisposable, FluffyUnderware.Curvy.Generator.CGDataRequestParameter[] requests) [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.CGModuleInputSlot.GetData[T] (System.Boolean& isDataDisposable, FluffyUnderware.Curvy.Generator.CGDataRequestParameter[] requests) [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.Modules.BuildShapeExtrusion.Refresh () [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.CGModule.doRefresh () [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.CurvyGenerator.Refresh (System.Boolean forceUpdate) [0x00000] in <00000000000000000000000000000000>:0
at FluffyUnderware.Curvy.Generator.CurvyGenerator.Initialize (System.Boolean force) [0x00000] in <00000000000000000000000000000000>:0

[_Aka_]

Hi,
Let's divide this into 2 issues:

Issue A: The build issue.
I will try to reproduce it later today. Will keep you updated. If you have a simple reproduction case, please share it with me, that would help a lot.

Issue B: The forum issue.
I had similar issues in the past, due to the website hosting provider falsely considering the posted text as attack vector. I will write them with this occurrence of the issue. Hopefully it will be solved soon.

Thank you for your patience, and have a nice day.

[_Aka_]

Update 1:

Issue A:
I couldn't reproduce the issue with a build with my usual test scenes. I will need a reproduction case from you to be able to reproduce it.

Issue B:
Contacted the web hosting provider, awaiting their answer.

[_Aka_]

Update 2:
Issue B is now solved. Can you please confirm?

[TdayMFG]

Yes, it looks like I can add the stack traces without error now.

I can't really provide a simple repro case directly. The general steps of what happens to trigger this error:

1. Prefab is loaded via addressables
2. This prefab has a CurvyGenerator on  it, don't know how much these screenshots will help show the setup





3. When instantiated the error happens immediately with the provided callstacks. Before any of our custom code runs that actually specifies where the control points should be.

The generator doesn't really have anything  unusual on it so far as I can think. The only thing I've changed from the default settings really are the materials and I have disabled pooling on the splines as the generators are being pooled by us.

[_Aka_]

Hi
I tried to reproduce the issue but couldn't. Attached is my attempted reproduction case. Press the J button at runtime to instantiate the generator prefab. Feel free to build upon it to reproduce the issue.
Have a nice day.

[TdayMFG]

I'm still looking into this, I've modified some of the curvy code to try and debug and what's trigger the assert is that the cachedTransform in CurvySplineSegment is null. It's like Update is being called before Awake.

Code:

        public bool HasUnprocessedLocalPosition
        {
            get
            {
                Debug.Log($"Unprocessed Local Position: {this.lastProcessedLocalPosition.HasValue} . CT: {this.cachedTransform != null}");
                return lastProcessedLocalPosition.HasValue == false
                      || cachedTransform.localPosition.Approximately(lastProcessedLocalPosition.Value) == false;
            }
        }

Added this logging to debug.

I just tried having it used "this.transform" instead of cached transform and the case is still hit.

Something is marking the spline segment for destroy yet this update is still happening.

EDIT: So I made a refactor too allow Curvy to do the pooling for the segments instead of using our own logic and, with the pool on the segments enabled, the error does go away.

While I can use this in the short term, being able to control the lifetime of an entire curvy hierarchy is important.

We use addressables and some async code pretty heavily so it's possible some of the Destroy calls curvy was making weren't on the main unity thread leading to this issue. Maybe this is something that gives you an indication of how this can be safely allowed?

[_Aka_]

Many Unity API calls fail when called outside of the main thread. This Unity limitation makes running random Unity code on a secondary thread often problematic. One has to identify which code is safe for threading, run it on a thread, then come back to the main thread to run the rest of the code. When not having the time or ability to dissect the code, the safest solution is to run the code on the main thread.
Curvy Splines already parallelize most of the code which can benefit from parallelization. So running Curvy Spline's code on the main thread seems to be the safe solution.