The crash occurs when the following conditions are met:
1) FBodyInstance is initialized via async code path (i.e. on worker thread instead of game thread).
2) CreateShapes_AssumesLocked returns false, indicating failure.
Under these conditions in UE 5.8, the following occurs:
1) CreateShapes_AssumesLocked return false, indicating failure.
2) As a result of the failure, Instance->BodySetup is set to null.
3) Execution proceeds to FBodyInstance::InitDynamicProperties_AssumesLocked.
4) Despite Instance->BodySetup being null, GetBodySetup called at the top of InitDynamicProperties_AssumesLocked returns non-null due to UE 5.8 addition of FBodyInstancePhysicsCreationInputs::ResolvedBodySetup.
5) InitDynamicProperties_AssumesLocked proceeds, leading to null pointer deference.
Conversely in UE 5.7, the following occurs:
4) Because Instance->BodySetup is null, GetBodySetup called at the top of InitDynamicProperties_AssumesLocked returns null.
4) InitDynamicProperties_AssumesLocked returns early, avoiding null pointer dereference.
In terms of a workaround:
1) Instance->BodySetup == null is no longer a reliable indication that physics creation failed. Instance->ActorHandle == null seems the next best indication.
2) To recreate the behavior of step 4 in UE 5.7, it seems safest to make InitDynamicProperties_AssumesLocked early out if Instance->ActorHandle == null.
[Attachment Removed]