This is a crash which would show up occasionally in our Backtrace crash database with little useful information in the logs, but we actually have a solid repro case now. When running the TestSIE (standalone in editor, presumably) unit test in the editor, we crash 90-100% of the time with this same callstack and information. The FComputeGraphTaskWorker tries to SubmitWork(), but the data in KernelInvocation.BoundProviderIndices is bogus, so it fails a RangeCheck when accessing GraphInvocation.DataProviderRenderProxies.
When looking at the values stored in the BoundProviderIndices array, it looks like the first two elements are storing a memory address fairly close to the location of the Data pointer within the TArray:
[Image Removed]
Looking at that memory location (0x0000021c8a592c40), it definitely seems to point at some sort of PCG generation data structure, as in the Memory window you can see a string just after this point “Biome_Evergreen_Groundcover_Volume_1”.
[Image Removed]This looks like the same string as this (although stored at a different location) with the first 4 characters “PCG_” overwritten with some other binary values:
[Image Removed]
One time while running this unit test, instead of hitting this particular crash, we instead ran into a deadlock situation where we got to this same point on (I believe) the same task worker, but one of the DataProviderRenderProxies (an FPCGLandscapeDataProviderProxy) deadlocks in AllocateResources because it’s trying to grab an FGCScopeGuard, but the Game Thread is stuck in GC waiting for the RT frame to complete. The similarity in repro steps and PCG being involved in both leads me to believe that these are related issues.
In the 5.6.1 Hotfix release notes, there are several PCG-related items listed, including these two which seem highly relevant:
UE-294237 [PCG] Fix editor deadlock when repeatedly refreshing PCG graphs containing GPU nodes
UE-297867 [PCG] Graphs with GPU nodes crash the build when launching standalone from editor
Both of these issue tracker entries appear to be non-public. Would it be possible to confirm whether these particular issues we’re seeing are the ones handled by those 5.6.1 changes? And if so, are there specific CLs that we could integrate from Perforce, or is it preferable to try to integrate the entire 5.6.1 change set as a block?
[Attachment Removed]