4.18 crash after destroying DestructibleComponent

Development World Creation
, , , ,
21

Hi Ori,
I’ve integrated that CL into the 4.18.1 source from github and made a new version for our users. Unfortunately I’m not able to repro the crash myself, but we’ve had reports from several users about it. One has sent me a dump file, which you can find here along with the symbols and log:

https://drive.google.com/file/d/1g7jvY4bCx25ukMkRxobVzGqbOFd1zInv/view?usp=sharing

Looking through this thread, it’s possible that one difference in repro is that I’m not actually destroying any destructible components themselves. Instead, in our game the user can undo destruction, and then the destroyed object should be restored to its intact state. To do this, I have the following function that’s called in the PostPhysics tickgroup, which as you can see sets the mesh to null and then back again:

void UDADecoSceneRecordingComp::RestoreFromStateCache()
{
	UWorld* World = GetWorld();
	FPhysScene* PhysScene = World->GetPhysicsScene();

	PxScene* PSceneasync = (PhysScene->HasAsyncScene()) ? PhysScene->GetPhysXScene(PST_Async) : nullptr;
	SCOPED_SCENE_WRITE_LOCK(PSceneasync);
	PxScene* PScenesync = PhysScene->GetPhysXScene(PST_Sync);
	SCOPED_SCENE_WRITE_LOCK(PScenesync);
	GPhysCommandHandler->Flush();

	int32 num = m_stateCache.Num();
	for (int32 i = 0; i < num; i++)
	{
		int32 idx = m_stateCache[i].m_idx;

		bool isFractured = m_stateCache[i].m_fractured;

		UDestructibleComponent *comp = (m_destructibles.IsValidIndex(idx)) ? m_destructibles[idx] : nullptr;
		if (comp)
		{
			if (isFractured != comp->m_isFractured)
			{
				if (!isFractured)
				{
					// restore the mesh
					UDestructibleMesh * mesh = comp->GetDestructibleMesh();
					comp->SetDestructibleMesh(nullptr);
					GPhysCommandHandler->Flush();
					comp->SetDestructibleMesh(mesh);
				}
				comp->m_isFractured = isFractured;
			}
		}
	}
}

Perhaps this method is not appropriate, although it worked fine in 4.17 and earlier.

Let me know if you’d prefer a new udn thread about this.

22

Unfortunately there won’t be a github commit until my change gets copied up to main in December 13. This will come with a series of other changes so it may be hard to discern what to take. Do you have access to our P4?

23

Hi Ori,
I’ve been unable to get my p4 login to work. I’ve contacted the epic support about it to see what’s up.
I guess there’s no chance of a 4.18.2 build with your fix? Otherwise waiting for 4.19 shouldn’t really be a huge problem. As long as it’s before Febuary, which is our target ship date.

24

Hi again - my p4 access has been restored so I can see the CL now, thanks!

25

It’s best to make a new UDN post about this and we can loop in nvidia as needed

26

Hi,

I think a new UDN post would be best for this. I will say that while changing this code I hit a crash because I was not properly flushing the command handler (accidentally commented out code) and because the new code calls fetchResult and syncs immediately it was much easier to reason about the problem which was that my FPhysxUserData which was part of the original component was going away, but I was not deleting the actual physx actor. I don’t think this is the same issue necessarily but just pointing out that with this change it should be easier to debug the problem