What causes a slow memory leak that only shows after hours?

Something keeps a growing set of objects reachable (an event subscription, a static list, or a cache without eviction), so the heap climbs steadily and only causes an out-of-memory crash after a long session.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Find a Slow Memory Leak Using a Heap Snapshot Diff

Quick answer: Take a baseline heap snapshot, run the game through the suspected loop many times, take a second snapshot, diff them to find the type that grew, then follow the retaining-reference chain to the root that holds it.

A leak that crashes after six hours will never show up in a thirty-second profiling session. You catch it by comparing the heap before and after repeating an action, looking for the object count that only goes up and never comes back down.

How to hunt it

1. Snapshot a clean baseline

Open the Memory Profiler, settle the game in a steady state, and capture snapshot A. This is your reference point for what the heap should look like.

2. Repeat the suspected loop, then snapshot again

Do the action you suspect (open and close a menu, load and unload a level) dozens of times, then capture snapshot B. Repetition turns a tiny per-cycle leak into an obvious delta.

3. Diff the two snapshots

Use the Memory Profiler's compare mode to show which object types grew between A and B. The type whose count rose by exactly the number of repetitions is your leak.

4. Follow the references back to the root

Select a leaked instance and walk its Referenced By chain. The chain ends at the thing that never let go, usually a static collection or an event handler that was added but never removed.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Reproduce it once with full context and the fix writes itself. The hunt is the expensive part.