Address a vulnerability with WorldPSCPool on cleanup

Development Rendering
, ,
1

FWorldPSCPool::Cleanup may cause a checkf assertion when calling GetWorldSettings, if the current persistent level’s settings are null. This may happen after travelling from one Map to another with a multitude of streamed sublevels, and closing the application (PIE or non-shipping builds)

Observe that Cleanup is in fact prepared to handle this case, but as is, GetWorldSettings is instructed to assert.

One solution is to disable the check on GetWorldSettings, and let FWorldPSCPool correctly handle this outcome:

if (AWorldSettings* WorldSettings = World->GetWorldSettings(false, false)) { ...

2

Thanks Dan, we likely need to replicate this into Niagara’s PSC pool also.

Did you have a repro case for this at all, as it’s not something we have encountered?

Thanks,

Stu

3

Thanks Dan,

I thought based on the original description that it might be something quite hard to get an isolated repro for :slight_smile:

I’ve changed both paths in CL 43278768 (UE5 Main), and tested out what I can. As you said there was already an assumption this could be nullptr, we likely just missed that argument.

I so have some niggling worry about leaking components but I don’t think that should happen, if you do encounter it let me know and I can dig in to it.

Thanks,

Stu

4

Hey, Stu!

Thanks for the response. We started running into this assertion right after switching to 5.6, but unfortunately, don’t have an isolated repro case. Our setup runs like this:

  • Game starts in a “Hub” level.
  • Player picks an option to jump to a different level B, using GameplayStatic’s OpenLevel
  • Level B programmatically streams in a large number of sublevels (~25), each with its own VFX, geometry, etc.

This assertion will happen frequently (and not always) when running this flow and closing PIE, and never if we directly run B in PIE. I can see that, using the flow, the world we’re getting settings from on cleanup is the sublevel’s. Some will contain a PersistentLevel, and some won’t. While if we directly load and run level B, World is always B.

This could be the way we’re configuring or streaming the sublevels. Streaming is simply:

// where World is always the currently active world (B), regardless of flow

World->SpawnActor<ALevelInstance>(..)

Because the Cleanup calls expect that WorldSettings might not exist, I thought “maybe there is a curious optimization now in place” :slight_smile:

I haven’t encountered this on UNiagaraComponentPool::Cleanup, but will keep an eye on it.

Thank you!!

Dan.

5

Thanks, Stu!