OSSv2, Steam, and OSSAdapter crash on exit

We are trying to use OSSv2 w/ steam and EOSServices, but we are running into a crash on exit. Our engine.ini file looks like this:

[OnlineServices]
DefaultServices=Epic
PlatformServices=Steam

[OnlineSubsystemSteam]
bEnabled=true
SteamAppId=...
SteamDevAppId=...
GameVersion=1.0.0.0
bVACEnabled=1
bAllowP2PPacketRelay=false
P2PConnectionTimeout=90
bUseSteamNetworking=false
DefaultLinkedAccountAuthTokenType=WebAPI:epiconlineservices

[EOSSDK]
bEnablePlatformIntegration=true
bEnableOverlayIntegration=true
+IntegratedPlatformManagementFlags=LibraryManagedByApplication

[OnlineServices.OSSAdapter]
+Services=(Service="Steam",ConfigName="Steam",OnlineSubsystem="Steam",Priority=1000)

but when the game shuts down, it crashes because AchievementInterface (and other interfaces like leaderboards, identity, etc. in steam) are not unique since the OSSAdapter (specifically things like the AchievementAdapter, SocialOSSAdapter, etc.) is still holding references to the relevant interfaces.

It looks like OSSAdapter module loads first, then the common user services loads the Steam module at some point in user initialization. Because steam is loaded after, when the ModuleManager shutsdown, it reverse sorts it to get unloaded before the OSSAdapter unloads. If, however, the OSSAdapter unloads first (through debug hackery), there aren’t any issues. I’m wondering what the fix here is. Should we be investigating some way to change the unload order? Is there something wrong w/ the way the config is setup?

Or an alternative approach I tried was renaming

void FOnlineServicesOSSAdapterModule::ShutdownModule()

to

void FOnlineServicesOSSAdapterModule::PreUnloadCallback()

This fixes the issue since the UnregisterServicesFactory call inside Shutdown, causes the Adapter interfaces to stop referencing the Steam interfaces. While it works, I’m concerned about breaking the paradigm of what PreUnloadCallback and ShutdownModule are meant to do.

Hi,

Thank you for the report! I’ve opened a new issue for this, UE-348586, which should be visible in the public tracker in a day or so.

I’m asking around to get some more input on your workaround, but if you run into any issues with it in the meanwhile, please don’t hesitate to reach out.

Thanks,

Alex

Hi,

After discussing this with someone more familiar with module loading/unloading, that change does seem to be a reasonable workaround while we continue investigating the issue. Please let us know if you run into any issues with it though.

Thanks,

Alex