Temporary UObject creation and cleanup

Development Programming & Scripting C++
1

We’re seeing lots of UObjects pile up from temporary UObjects created both in-Editor and during PIE (we use them at runtime and recreate them at other points for debug and other purposes). They don’t seem to be getting garbage collected, and forcing GC every frame in the editor only stops newly-created objects hanging around - it doesn’t clean up the existing objects.

We’re creating them like this:



{
    // SomeUClassPtr is TSubClassof<UMyObject>
    UMyObject* Obj = NewObject<UMyObject>(GetTransientPackage(), SomeUClassPtr);
    // do stuff with Obj - no references from UProperties
} // Obj goes out of scope

Is that correct? I assume we want them in the transient package as we don’t want them to get saved. Should we expect to see these objects getting destroyed frequently?

We’re mainly concerned about slowdowns and crashes in extended Editor or gameplay runs.

3

No, you really can’t. UObjects are handled by the garbage collector and can’t be deleted directly. Please don’t suggest stuff that will cause guaranteed crashes.

The code looks fine and I’d expect them to be GCd. You can use the console command


obj refs name="myobjname"

to dump output on reference chains to see what’s keeping an object alive (the command can be slow).


obj list class="myclassname"

is useful too if you don’t know the names.

4

Thanks very much, I’ll give those console commands a go. Documentation seems sparse, where should I be looking in the source to find these kinds of commands?

5

You can call ‘MarkPendingKill()’ on the object before it goes out of scope, that should force GC to clean it up on the next pass.

Could be wrong here, but IIRC the transient package won’t clean up until the current UWorld is unloaded so that might be what’s keeping it around.

1 Like
6

Ah that explains it. Yeah we discovered MarkPendingKill helped, we’ll keep using that then. Often we just want the objects around for the scope of a single function.