Mixedrealitytoolkit-unity: Null Ref Follow Solver - Hand Interaction Example VR

[CDiaz-MS]

Describe the bug

NullReferenceException: Object reference not set to an instance of an object
  at Microsoft.MixedReality.Toolkit.Experimental.Utilities.Follow.get_ReferencePosition () [0x00000] in C:\MRTK\ReleaseTesting\Leap_2018_5-18\Assets\MRTK\SDK\Experimental\FollowSolver\Follow.cs:330 
  at Microsoft.MixedReality.Toolkit.Experimental.Utilities.Follow.GetReferenceInfo (UnityEngine.Vector3& refPosition, UnityEngine.Quaternion& refRotation, UnityEngine.Vector3& refForward) [0x00001] in C:\MRTK\ReleaseTesting\Leap_2018_5-18\Assets\MRTK\SDK\Experimental\FollowSolver\Follow.cs:697 
  at Microsoft.MixedReality.Toolkit.Experimental.Utilities.Follow.SolverUpdate () [0x00013] in C:\MRTK\ReleaseTesting\Leap_2018_5-18\Assets\MRTK\SDK\Experimental\FollowSolver\Follow.cs:351 
  at Microsoft.MixedReality.Toolkit.Experimental.UI.MixedRealityKeyboardPreview.ApplyShellSolverParameters () [0x000ba] in C:\MRTK\ReleaseTesting\Leap_2018_5-18\Assets\MRTK\SDK\Experimental\MixedRealityKeyboardPreview\MixedRealityKeyboardPreview.cs:204 
  at Microsoft.MixedReality.Toolkit.Experimental.UI.MixedRealityKeyboardPreview.OnEnable () [0x0000e] in C:\MRTK\ReleaseTesting\Leap_2018_5-18\Assets\MRTK\SDK\Experimental\MixedRealityKeyboardPreview\MixedRealityKeyboardPreview.cs:130 

To reproduce

Steps to reproduce the behavior:

1. Add latest foundation 2.4 package
2. Open the hand interaction scene
3. Make sure the profile is the DefaultMixedRealityProfile
4. Standalone build, make sure to check Development Build
5. Start the app, open the log file

Your setup

• Unity Version 2019.3.12f1
• MRTK Version v2.4

Target platform

• WMR immersive
• OpenVR

[keveleigh]

Possibly a long shot, but a null ref like this could easily lead to the unexpected behavior described in #7912 and #7624, which are both also based on solvers I believe. Since this one appears to be a race condition, I wonder if these three issues are related.

[keveleigh]

This is new code added in 2.4 (#7413), so I propose this as a release blocker. We shouldn't ship with a potential null ref.
It seems like a race condition, so perhaps moving the ApplyShellSolverParameters() call to Start() could fix things? Haven't investigated any possible side effects. @Cameron-Micka Do you remember if it has to stay in OnEnable?

[Cameron-Micka]

Ah weird, even though SolverHandlerget's assigned in Awake it's null by the time we get to OnEnable?

Moving ApplyShellSolverParameters() to Start should be fine.

If the race condition can't be tracked down, it might make sense to turn protected SolverHandler SolverHandler; into a gettor with lazy initilization.

[keveleigh]

Ah weird, even though SolverHandlerget's assigned in Awake it's null by the time we get to OnEnable?

Every script gets its Awake and OnEnable called back-to-back, so if the keyboard is initialized first, neither of SolverHandler's methods will have been called yet.

[Cameron-Micka]

Oh gotcha, I forgot those calls were not interleaved between objects.