We’ve noticed a rare issue with FastGeoAsyncRenderStateJobQueue where FJob::FastGeo has a chance to get destroyed before FFastGeoAsyncRenderStateJobQueue::FJobSet::OnPostExecute_GameThread can execute. It then crashes when attempting to run Job.OnPostExecute_GameThread(). Updating FJob::FastGeo to be a weak ptr seems to have resolved this issue, but we have some concerns that we may be missing something since these objects are destroyed before the process is complete.
Is this a known issue, if yes what would your recommended fix for it be?
This issue may have been fixed in UE6 CL#57638612 (9623ab) [FastGeo] Fix crash when an async render state job outlives its container
- Changed FFastGeoAsyncRenderStateJobQueue::FJob to hold its container in a TWeakObjectPtr instead of a raw pointer, so resolving it reads an object index and serial number rather than memory that may already have been reclaimed. The previous guard, ::IsValid on a raw pointer, was itself the use-after-free because testing the object reads it.
- Pinned the container across FJob::Execute so a pipe worker cannot have it collected mid-call. FJob::OnPostExecute_GameThread and AddJob only resolve it, since both run on the game thread where garbage collection cannot run concurrently.
- Rejected a job in AddJob when its container no longer resolves, before it enters the pending set, and compared jobs by index and serial number so equality stays consistent with the hash once a container has been collected.
- Removed the unused FJob::IsValid, whose TWeakObjectPtr::IsValid is documented as returning false incorrectly off the game thread during the mark phase.
- Covers the reported repro rather than changing code for it: a streaming cell that reaches LoadedNotVisible and is discarded without ever becoming visible skips UWorld::RemoveFromWorld, leaving its PrecachePSOs job orphaned rather than cancelled. That job now resolves to null and does nothing instead of using a collected container.
Can you see if integrating that change fixes the crash you’re seeing?