Steps to Reproduce
Hello,
following up on Unreal Engine Issues and Bug Tracker (UE-182925) which has EPS post [After upgrading to 5.4 the cooker crashes at the end of the [Content removed]
We’re able to get this 100% of the time while cooking in 5.7.0-release but its basically near the start of a cook, and in particular seems to occur for us on a blueprint actor that has a lot of components (200+) including child actor components inside a very small “lobby” level.
So far what I’ve seen is:
* Level gets loaded and rapidly goes through world creation, serialization, and world destruction. (Level is small enough and after all DDC content is generated, takes under 3s to load / save / destroy map).
* Phys solver is destroyed upon world destruction (effectively pulling the rug out from under the physics bodies are still lingering in primitive components), I set data breakpoints to catch this occurring and where the physics reference was being updated in the final solver sync during destruction.
* Very shortly later, GC clean-up occurs and goes through destroying physics state. Crashes due to invalid pointer trying to resolve the Solver to destroy the underlying physics state objects.
* I’d expect that world destruction should be tearing down / clearing up the components but seems like its not the case (concerning)
The callstack is different. What I haven’t been able to verify yet is if there is widespread in our cook or related to the specific content (content issue potentially vs system issue as a short term fix). I have started to look at intercepting the initial body creation work that can occur in the finalization steps that occur as part of solver teardown and actually nulling out the reference, but not sure yet if that’ll produce any meaningful results.
Note: if we actually remove new creation when we’re shutting down, we’ll get the original callstack at the end of the cook. Specifically in
- FPBDRigidsSolver::ProcessSinglePushedData_Internal, ProcessProxyPT lambda, if I modify const bIsNew to not create new elements when shutting down
- PrimitiveComponentPhysics.cpp - GetPhysicsObjectById - Add null check ( BodyInstance.ActorHandle->GetPhysicsThreadAPI() == nullptr) to catch on the game side (ugly)
This will get us past the immediate blow-up during GC and we’ll get the original issue as reported. Please let me know if I can provide any more information. I’m highly doubtful I can package up the content project but can try to assist with any other debugging. Parallel callstack didn’t provide much at the time of crash.
Anyway, this is 100% repo for us. In particular the incorrect lifetime management of the physics teardown with the world it belongs too seems like the culprit. I feel like waiting for GC will always leave a high risk that the world itself is gone and so is the solver / scene associated with it.
[Image Removed]
PBDRigidSolver.cpp - const bool bIsNew = !IsShuttingDown() && !Proxy->IsInitialized();
PrimitiveComponentPhysics.cpp
Chaos::FPhysicsObject* UPrimitiveComponent::GetPhysicsObjectById(Chaos::FPhysicsObjectId Id) const
{
if (!BodyInstance.IsValidBodyInstance() || BodyInstance.ActorHandle->GetPhysicsThreadAPI() == nullptr)
{
return nullptr;
}
return BodyInstance.GetPhysicsActor()->GetPhysicsObject();
}
[Attachment Removed]