We’re occasionally seeing a crash in UE5.6 in CacheRayTracingPrimitive (in PrimitiveSceneInfo.cpp), when we hit the following check:
check(SceneInfo->GetRayTracingLODDataNum() == 0);
As far as we can tell, there doesn’t seem to be any particular correlation to points in the game, content etc when the crash occurs - it seems intermittent. I’m not deeply familiar with the code for building the RT acceleration structures, but this looks like some sort of race condition potentially - if the code expects the FPrimitiveSceneInfo::RayTracingLODData to be empty at this point but it is not, then that suggests something is happening out of sequence. (We’re currently using r.GTSyncType=1 on this platform, if that makes any impact on this issue.)
Obviously in a Shipping build the check will be compiled out and won’t trigger a crash, but my concern is that if FPrimitiveSceneInfo::RayTracingLODData is getting overwritten here then we’ll not see the proper cleanup from FPrimitiveSceneInfo::RemoveCachedRayTracingPrimitives happening, and we might be leaking resources.
Is this a crash you’ve seen before at all, and have you got any ideas where it might be coming from? We’ve had a look at the changes to this code in 5.7, but we can’t see any relevant fixes that might address this bug.
It’s possible this potential race condition has to do with updating bCachedRaytracingDataDirtyand other bitfield members of FPrimitiveSceneInfo similar to what was reported in [Data race on FPrimitiveSceneInfo’s [Content removed] in which case you could try testing the same workaround while we investigate:
"bNaniteRasterBinsRenderCustomDepthand bIsCachedRayTracingInstanceValidare stored on two different byte but on the same word. While testing this I also found two other potential overlap : bPendingAddStaticMeshes/bPendingFlushRuntimeVirtualTexture (both set in the same AddStaticMeshesTask) and bNeedsCachedReflectionCaptureUpdate (set on the RenderThread).
I’ve moved all the variables written by tasks to their own bool instead of being part of the bitfield, which fixed the original issue and potentially others."
We have an internal issue tracking this which I’ll look into making public.
That said, it’s possible there are scenarios that could be causing this we need to check into, but you are right to be wary of leaking resources in a shipping build.