Found after updating a project from 5.7 to 5.8 @ CL54667078. Also present in //UE5/Main. Requires p.Chaos.EnableAsyncInitBody=true. Same content ran fine in 5.7.
Crash
FChaosEngineInterface::SetSleepThresholdMultiplier_AssumesLocked ChaosEngineInterface.cpp:1261
FBodyInstance::InitDynamicProperties_AssumesLocked BodyInstance.cpp:4710
TInitBodiesHelperBase<>::InitBodies BodyInstance.cpp:1704
Cause
When CreateShapes_AssumesLocked returns bInitFail (NumShapes == 0), the failure path (BodyInstance.cpp:1577) releases the actor handle and nulls Instance->BodySetup, but leaves the instance in Bodies[]. InitBodies() then calls InitDynamicProperties_AssumesLocked() on it (:1704).
UE 5.7 caught this with if (!BodySetup.IsValid()) return;. 5.8 uses if (!GetBodySetup()) return;, and GetBodySetup() (:1381) now prefers GetAsyncPhysicsCreationInputs()->ResolvedBodySetup, which is never reset on the failure path — so it returns a live UBodySetup and the guard passes.
FPhysicsInterface::IsDynamic() is !IsStatic(), and IsStatic() returns false for an invalid handle, so it returns true for nullptr. SetSleepThresholdMultiplier_AssumesLocked then dereferences null.
Suggested fix
void FBodyInstance::InitDynamicProperties_AssumesLocked()
{
+ // Shape creation may have failed and released the actor handle, leaving this
+ // instance in Bodies[]. IsDynamic() returns true for a null handle.
+ if (!FPhysicsInterface::IsValid(GetPhysicsActor()))
+ {
+ return;
+ }
+
UBodySetup\* ResolvedSetup \= GetBodySetup();
if (!ResolvedSetup)
{
// This may be invalid following an undo if the BodySetup was a transient object
return;
}
Note on our content
Our data is also wrong here — a component requesting collision from a mesh with no collision geometry is meaningless, and we’re fixing that separately. But the engine already decided to fail that body and released its handle, so it shouldn’t then walk into a null dereference. 5.7 tolerated the same content silently.
[Attachment Removed]