BiteSizedChunks.comLearn one small thing at a time.
Course contentsShow
← Unreal Engine Game Development
Lesson 172 of 8803. C++ and UObject ArchitectureFree lesson

Detecting Memory Leaks with Object Profiling Tools

Utilize Unreal's memory tracking tools to identify objects that are failing to be garbage collected due to circular references or improper rooting.

In this lesson, you will learn how to use Unreal Engine’s built-in memory profilers to track down objects that refuse to be cleaned up by the Garbage Collector (GC).

Understanding the Leak

In Unreal’s UObject system, objects are automatically destroyed when they are no longer referenced by any UPROPERTY. A "memory leak" occurs when you inadvertently hold a hard reference to an object that should have been destroyed, preventing the GC from reclaiming its memory. This is common with circular references (Object A points to B, and B points back to A) or when an object is accidentally marked with AddToRoot.

Using the Object Profiler

To diagnose this, Unreal provides the Memory Profiler and Object List tools. You can access these via the console while running your game:

  1. obj list: This is your most powerful starting point. Open the console (press ~) and type obj list. This prints a massive list of all currently loaded UObjects.
  2. Filtering: To find specific culprits, use obj list class=MyClassName. If you see instances of a class that should have been destroyed, you have confirmed a leak.
  3. Investigating References: If you find an object that shouldn't be there, use obj refs name=MyObjectName. This reveals exactly which other objects are currently holding a hard reference to it, preventing the GC from running.

Identifying the Culprit

Imagine you have a UWeaponManager that you expect to be destroyed when a level ends. If you run obj list and see an instance still present, run obj refs name=WeaponManager_1.

You might see an output like:

WeaponManager_1 is referenced by:
  - InventorySystem_0 (Property: ActiveManager)

This tells you exactly where the problem lies: your InventorySystem still holds a UPROPERTY pointing to the manager. You now know you must either nullify that reference or use a TWeakObjectPtr to break the connection. By analyzing these reference chains, you can systematically dismantle the links keeping "zombie" objects alive in your memory.

Key Takeaway: When an object persists unexpectedly, use obj list to confirm its existence and obj refs to pinpoint the specific UPROPERTY preventing its garbage collection.