Crash when a subsystem calls GetSubsystemArray() on its owner while engine code is iterating on subsystems also obtained through GetSubsystemArray()

In some occasions, engine code iterates over a certain subsystem type by calling FSubsystemCollection::GetSubsystemArray() and then calling some method on all subsystems of the returned array. This happens, for example, in UWorld::BeginPlay(), which iterates over subsystems of type UWorldSubsystem in an internal SubsystemCollection and calls OnWorldBeginPlay() on each one.

Now, subsystems in general have access to their owner and can call GetSubsystemArray() on it, which forwards the call to the owner's internal SubsystemCollection. If this is done while subsystems are being iterated on (for example, inside a World Subsystem's OnWorldBeginPlay() method), a crash can occur shortly after.

The crash can be explained as follows:

• FSubsystemCollectionBase caches subsystems of each class and subclass in a TMap<UClass*, TArray<USubsystem*>>.
• FSubsystemCollectionBase::GetSubsystemArrayInternal() checks if the map above contains the requested subsystem class. If it does not, it adds a new array entry to the map and populates the array with all subsystems of that class. At the end, the method returns a direct reference to the array contained in the map.
• However, if adding a new array entry to the map causes it to reallocate its internal storage, all array references returned so far can be invalidated.
• Engine code that iterates on subsystems often get the returned array reference and iterates over its elements. See UWorld::BeginPlay() iterating over UWorldSubsystems and calling OnWorldBeginPlay() on them.
• During such an iteration, if a subsystem calls GetSubsystemArray() on its owner, the resulting call to FSubsystemCollectionBase::GetSubsystemArrayInternal() can cause the internal map storage to be reallocated, which invalidates the array reference currently being used by the outer iteration code. And this can lead to a crash on the next iteration.

A quick fix was suggested in the related UDN case: code that iterates over subsystems (such as UWorld::BeginPlay()) could make a copy of the subsystem array and iterate on that. Alternatively, FSubsystemCollectionBase::GetSubsystemArrayInternal() could return the array by copy to all of its clients. Another possibility would be to rework the mechanism used by FSubsystemCollectionBase to cache subsystems.

=== Repro Project ===

• Download, compile and open the repro project available as an attachment of the linked UDN case
• Start and Stop PIE. Open the Output Log and show only "LogRepro" category.
• The log will show a list of pointers before and after repeated calls to GetSubsystemArray() from a UWorldSubsystem's OnWorldBeginPlay() method. Note that the first few pointers got invalidated, including the pointer to the array that is being iterated on by UWorld::BeginPlay() at that time. Check the project's "MyWorldSubsystem.cpp" file for details.

=== Blank Project ===

• Create a blank C++ project
• Add some trivial subclasses of "UWorldSubsystem" with only UCLASS() and GENERATED_BODY()
• Add another class "UMyWorldSubsystem" derived from "UWorldSubsystem"
• Override method OnWorldBeginPlay(). Implementation:
• Call InWorld.GetSubsystemArray() or GetWorld()->GetSubsystemArray() with "UWorldSubsystem" and then several times with the various trivial subclasses created previously.
• Repeat all of the calls above a second time.
• Compile and open the project, then start PIE.
• Using UE_LOG or breakpoints and watches, note that the address of the returned array is different for the first and second call to GetSubsystemArray<UWorldSubsystem>.