I am encountering reproducible server Animation memory retention when an Animator is destroyed and recreated following a player respawn.
The problem reproduces in a completely empty baseplate using a minimal server-only Tool, though this also occurs when done on the client. The Tool loads exactly three fixed animations once onto the player’s Animator. Animation memory remains stable for the remainder of that character’s life, including repeated reuse of the loaded tracks.
After resetting the character, most of the Animation memory is eventually collected, but it never returns to its previous settled level. Equipping the newly cloned Tool on the new character loads the same three animation IDs onto the new Animator, and the post-collection memory floor rises again.
Repeating this produces a staircase pattern: each character life leaves behind an additional permanent amount of server Animation memory.
Animator:LoadAnimation() is called exactly once for each pool entry and exactly once per Animator. Equip and unequip cycles during the same character life reuse the existing tracks.
During teardown, every owned track is stopped and destroyed, the track table is cleared, character/Animator connections are disconnected, and the top-level state reference is cleared.
Neither track counter ever exceeds three during a character life, meaning there is no AnimationTrack leak, and the server leak is seemingly on the engine level, out of my control.
Reproduction steps:
- Start a playtest
- Navigate to Developer Console > Memory > Server, and sort by highest memory to find Animation memory, keep it open
- Equip the dance tool a few times so that all 3 anims are loaded, observe the expected memory spike
- Toggle server view and confirm that the Tool’s LoadedTrackCount attribute is 3
- Reset, and load all 3 animations again, repeat
For each character life:
- The same three tracks load and Animation memory rises.
- Memory remains stable while that Animator continues to exist.
- Reset destroys the character, Animator, Tool, and tracks.
- Animation memory eventually falls, showing that collection occurred.
- The settled memory floor remains permanently higher than before.
- The next character repeats the same pattern with the same three IDs.
The residual increase accumulates across resets and does not return to the original baseline.
Impact
This becomes significant in games with frequent player deaths, respawns, and applying humanoid descriptions.
The original game where I ran into this problem has observed continuously increasing server Animation memory over long-running sessions. Even a small retained allocation per destroyed Animator can accumulate sufficiently to contribute to server memory pressure and eventual crashes.
Repo
AnimationMemory_Repo.rbxl (55.1 KB)
The three animations might not be accessible, and may have to be replaced with platform animations
