The PlayFab Unreal SDK uses a mix of UPROPERTY and TSharedPtr to reference UObjects. This is not valid use of the unreal memory systems.
UObjects in unreal are garbage-collected, and should only be referenced via UPROPERTY, via fields listed in the the AddReferencedObject callbacks, or via TWeakObjectPtr or TStrongObjectPtr. These references are known by the GC and are used when checking for reachability, and when collecting objects and nulling references to collected objects.
Handling these via TSharedPtr will have two systems competing over the same memory allocation, and inevitably resulting in crashes. TSharedPtr is also not known to the GC, and will not be reset to null when the object is collected. Rather, the TSharedPtr will point to deallocated (or even reallocated) memory.
A patch for this was introduced a while ago where the deleter used in the TSharedPtr instances was overridden to destroy the object via the GC heap, and the instances were created with the GC standalone flag. This worked fine as long as the UObjects (the authentication context) were only referenced via TSharedPtr.
With more recent additions to the SDK, the UObjects are now referenced both via TSharedPtr and UPROPERTY, and are not always created with the standalone flag.
This results in premature garbage collection and the pointers inside TSharedPtr are left dangling.
We have patched this by replacing all occurrences of TSharedPtr referencing a UObject with TStrongObjectPtr. This solves the issue and is correct from the POV of the UE garbage collector.
Without this patch, we had frequent crashes due to PlayFab objects being prematurely collected, and dangling references to said objects, all from within the PlayFab SDK.