Geometry Collection cluster handles leaking and causing ensures with field systems

Development Asset Creation
, ,
1
  1. Start simulating in test level (L_Test)
  2. Wait for the cube to fracture and run wp.Runtime.SetDataLayerRuntimeState Unloaded DL_Test to force the GC actor to unload (simulate going outside streaming range)
  3. Manually drag the bigger field system over the (now unloaded) cube
  4. Assert should trigger as soon as the cube overlaps the position it was on

Attached video demonstration

2

Steps to Reproduce
Hi,

We have been tracking down an assert that seems to happen occasionally when playing in FPBDRigidsSolver::BufferPhysicsResults, seemingly because the IPhysicsProxyBase* we get out from the handle during iteration has already been deleted.

After some debugging it seems these handles that still remain are always the ones created in FRigidClustering::CreateClustersFromNewIslands. These handles also seem to remain in FPBDRigidsSOAs::ClusteredParticles forever (even after unloading the relevant geometry collection actors), and the array keeps getting more and more invalid handles where the PhysicsProxy has already been deleted.

It seems that a field system we have that sets GCs to dynamic occasionally picks up one of these handles, and if the state wasn’t already marked as dynamic it gets included in the next FPBDRigidsSolver::BufferPhysicsResults, which then tries to read from the already freed memory PhysicsProxy.

I have set up a test project which seems to be able to reproduce the assert easily (included a video). In this case I ran the engine with -poisonmallocproxy to help trigger the assert and circumvent the logic reading old “valid” data in memory that could still be committed.

To simulate the actor unloading (in reality going outside streaming range) I have tagged it with a Data Layer and manually ran wp.Runtime.SetDataLayerRuntimeState Unloaded DL_Test.

I have included demonstration video.

Any help would be appreciated.

3

Hello [mention removed]​

Thank you for reaching out and taking the time to provide both a repro project and a demo video.

I was able to reproduce the assert by following the described steps.

I’ll investigate some more and get back to you.

All the best,

[mention removed]​

4

Hello [mention removed]​

Thank you again for the well-thought-out repro project and setup, as well as for providing your analysis.

I’ve tested and confirmed that the issue reproduces in the latest Perforce version, so there is no solution available at this moment.

I’ve made a JIRA report and included all this info.

Once the report is input to Epic’s internal system, a public trackable link will be available at: Unreal Engine Issues and Bug Tracker (UE\-315386)

Please note that this process can take some time.

We don’t provide updates on EPS, but if you would like to track the resolution, check the link for the status.

Once the issue is fixed, the link will also provide the CL with the code change that solves it, so you can update our local engine, in case you are not willing to wait for the engine version that fixes it.

I’ll close the case, but feel free to reply if you have anything else to add, and it will automatically reopen

All the best,

@Rafael Pinheiro