Summary
Loading a large Mesh Partition region (about 87 preview sections) freezes the editor permanently. Worker tasks in FStaticMeshTransformer::Execute block on a GameThreadNormalPri task (FinalizeStaticMeshesTask.Wait()) while the game thread spins in Mass FChangeListener::WaitForChange without running game-thread tasks. The worker pool fills up and the render thread waits forever in FlushPendingDeleteRHIResources_NonRealtime. A second blocking GetResult() in ProcessModifiers_TextureChannels freezes it the same way. I have a small patch that fixes both. Other transformers contain the same pattern, which I did not test.
What Type of Bug are you experiencing?
World Creation Tools
Steps to Reproduce
UE 5.8.3 source build, MeshPartition plugin, a project with a Mesh Partition using the MPD_Default data asset (RVT transformer included on Preivew / High End).
Open asmall level, then open a large level with about 87 preview sections.
Wait. The editor stops responding and never recovers. I created the the terrain with a heightmap click save and unload then try to load a big region.
Expected Result
The region loads. Memory-bound slowness is acceptable, but the editor recovers.
Observed Result
Observed Result
The editor freezes permanently, and I can reproduce it every time on the unpatched code. The render thread waits in FlushPendingDeleteRHIResources_NonRealtime (SubmitCompletionEventWait) and never returns. The GPU is idle.
All 85 to 88 command-list dispatch events are complete. Only the tail of DispatchPipe is incomplete.
In the debugger, 28 worker threads are parked in FStaticMeshTransformer::Execute → FTaskHandle::Wait.
The root of the task chain is a ready, unstarted GameThreadNormalPri task with no prerequisites.
The game thread is in UMassEntityEditorSubsystem::Tick → FProcessingQueue::Run → WaitForChange. That the pool starvation keeps the Mass workers from running is my inference from the stacks and source, not something I saw.
Affects Versions
5.8
Platform(s)
Windows
Additional Notes
This is the proposed fix which claude gave me. I did apply i successfully but this doesn’t fix the memory pressure, probably have to dig deeper.
Proposed fix
Claude summary:
The deadlock comes from worker tasks that block while waiting for tasks that only the game thread can run. I replaced those blocking waits with nested tasks, so the parent task completes only after the game-thread step finishes, and the worker is released in the meantime. The change is about 20 added lines in three files of the MeshPartitionEditor module:
FStaticMeshTransformer::Execute: UE::Tasks::AddNested(FinalizeStaticMeshesTask) replaces FinalizeStaticMeshesTask.Wait(). The task handles are now captured by value, because Execute returns before the nested tasks run.
UMeshPartitionEditorComponent::LaunchTransformers: Transformer_Task calls Execute on the transformer stored in the context, not on a lambda-captured copy, so the nested tasks can’t outlive it.
ProcessModifiers_TextureChannels: a nested follow-up task stores the result of RenderSectionChannels once it has finished, instead of the worker calling GetResult() and blocking on a game-thread render task.