As far as I could see, the freeze happens when waiting on the “DuringPhysics” TickGroup when processing the “EndPhysics” TickGroup.
Inside of “ReleaseTickGroup” for the TG_EndPhysics group, it calls
FTaskGraphInterface::Get().WaitUntilTasksComplete(TickCompletionEvents[Block], ENamedThreads::GameThread);
Where “Block” is “TG_DuringPhysics”. Looking into the “TickCompletionEvents” for Index 2 = TG_DuringPhysics, I can see a length of 26.
https://puu.sh/yim3q/f58196e872.png
It then proceeds to “Wail Until Tasks Complete”, by passing these Tasks for “DuringPhysics” TickGroup. So I guess it’s insight there. I wonder if any of you have different numbers for the amount of tasks. Would help me find out if it’s our actors or something engine internal.
Well and then it checks the tasks if they are complete or not. If it finds one non-complete task, it fires a Thread for “Process Tasks Until Quit”
This then calls "ProcessTasksNamedThread for each member of “Queue”, passing the Queue Index (which is the GameThread Enum passed ealier?!). So I guess that’s the GameThread queue. It then “pops” a member from the “StallQueue” , which seems to be invalid, and then running into “bAllowStall”. “bAllowStall” is driven by: FPlatformProcess::SupportsMultithreading()
I don’t know if disabling Multithreadding would do anything, but I hardly believe that’s the proper way to solve this issue.
I sadly don’t know which of the tasks fails, as that is obviously “optimized away”.
https://puu.sh/yimll/56823838fa.png
So yeah, finding out what task from the “DuringPhysics” group is doing bad things would be the best, or?