MechJeb Version

dev based on 42be0c9

KSP Version

1.6 64bit on win10

Description

Using the Unity win64 dev player from Unity 2017.1.3p1 (for live debugging in Visual Studio).
MechJeb started throwing NullReferenceExceptions on the main thread due to the FuelFlow simulation failing. Upon inspection the background thread continuously throws an exception that a Transform is being accessed on the background thread. (see exception below)
This doesn't happen using the normal game client (likely since the cross-thread checks are removed from release unity builds).
It seems to be related to changes in the fuel simulation where the engine module started being accessed on the background thread, instead of the appropriately state captured in FuelFlowSimulation.Init.

Please note that this is on a custom build, I also don't know if it's reproducible with the linux/mac unity dev client.

Replication Case

Steps:

• Use debug Unity client (.\Unity\Editor\Data\PlaybackEngines\windowsstandalonesupport\Variations\win64_development_mono)
• Load a game with a vessel already in flight
• Plan a Maneuver Node
• Execute Node in Maneuver Node Editor/Planner
  Result:
• Vessel will orient but not warp
• Exceptions in main thread due to Fuelflow stats not being ready (NullRef in MJMStageStats.RequestUpdate)
• Exceptions in background thread as shown below

Log Info

Background thread stacktrace:

Exception in MechJebModuleStageStats.RunSimulation(): UnityEngine.UnityException: INTERNAL_get_rotation can only be called from the main thread.
  at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_get_rotation (UnityEngine.Quaternion&)
  at UnityEngine.Transform.get_rotation () [0x00004] in C:\buildslave\unity\build\artifacts\generated\common\runtime\TransformBindings.gen.cs:95 
  at UnityEngine.Transform.get_forward () [0x00002] in C:\buildslave\unity\build\artifacts\generated\common\runtime\TransformBindings.gen.cs:90 
  at MuMech.PartExtensions.ThrustAtConditions (.ModuleEngines e, Double massFlowRate, Double isp, Boolean cosLoss) [0x00029] in .\MechJeb2\PartExtensions.cs:95 
  at MuMech.PartExtensions.EngineValuesAtConditions (.ModuleEngines e, Double throttle, Double atmPressure, Double atmDensity, Double machNumber, .Vector3d& thrust, System.Double& isp, System.Double& massFlowRate, Boolean cosLoss) [0x00024] in .\MechJeb2\PartExtensions.cs:63 
  at MuMech.FuelNode.SetConsumptionRates (Single throttle, Double atmospheres, Double atmDensity, Double machNumber) [0x00087] in .\MechJeb2\FuelFlowSimulation.cs:833 
  at MuMech.FuelFlowSimulation.SimulateStage (Single throttle, Double staticPressure, Double atmDensity, Double machNumber) [0x00006] in .\MechJeb2\FuelFlowSimulation.cs:110 
  at MuMech.FuelFlowSimulation.SimulateAllStages (Single throttle, Double staticPressureKpa, Double atmDensity, Double machNumber) [0x00024] in .\MechJeb2\FuelFlowSimulation.cs:82 
  at MuMech.MechJebModuleStageStats.RunSimulation (System.Object o) [0x000bd] in .\MechJeb2\MechJebModuleStageStats.cs:234

Yes. Unity object are not thread safe.

That's why MJ has to copy every parts in the FuelNode objects

Is Unity doing that because it is known that those APIs aren't thread safe?

yeah that makes sense. i've found that even Debug.Log isn't threadsafe and crashes.

i'll have to rework that change then, but i'm buried in work conferences all week.

I think this one got fixed.