Every time your character dies it leaks memory (up to 500 MB, probably infinite)

Does this only occur when the character is killed, or does respawning (LoadCharacter) in general cause this?


I believe the leak actually occurs on character load which means even player join probably leaks memory. Can’t be sure tho. Reproduction is optimized to show leak on death since there are no other players involved.

Chances are it leaks the same for other players too.

1 Like

Wow this seems like a serious issue! We run 30 player servers on Jailbreak and deal with a ton of character deaths. I have no doubt we’re losing substantial memory in some servers.

Edit: Looks like I’m misinformed! Still a big deal for memory!


This is all client side memory, so I have no idea what the server-side story is.

If you have a lot of filtered devices, this is maybe partially why.

Running out of memory is usually the cause of crashes. On an iPhone 6, we only have 1 GB of RAM, so something like this can actually be the difference between a crash and not.


Does this have to do with anything within Roblox programming and how dying inside of a game can cause a memory leak to be super high and very hectic, and occurring more often as time goes on for the Roblox engine that it can’t handle it?

I wonder how it can be fixed, especially with people who play Roblox on low-end devices because in the future it can cause some detrimental damage to those types of players.

1 Like

This has been our most problematic issue since releasing our game 99 Fail. We’ve narrowed down our source of server-sided memory leaks to almost solely the respawning of characters. This is particularly problematic for our game due to players constantly dying within servers as large as 80 players:

A typical server will crash (due to memory exhaustion) after only a few hours, and this was even worse before we switched from R15 to R6. We vigilantly track and cleanup memory via Janitors and have even resorted to now manually destroying the Character and Player instances ourselves.

Our game has streaming enabled with a 2 second respawn time. The vast majority of player respawns occur from their humanoids health being set to 0. We do call :loadCharacter but only rarely if streaming enabled causes them to fall past the kill parts.

Thanks for posting this engine report. We are confident this isn’t solely an issue with our game and would love to have it resolved, especially with David’s goal of empowering large 1000+ player servers.


Weird when I check my game and that’s always more than 200MB is used… is this same thing?

Isn’t the memory leak being caused by how Roblox handles death? I literally had a leak in my game not long ago because the Characters don’t get destroyed on death and all the connections I had on it were staying on the server (servers crashed), they just get parented to nil. Not sure, if objects like the character parented to nil will get Garbage Collected on the client.

I spawned and reset my character 2 times, not even kicking the player out destroyed them:


What are you using to track all of this? Are references being cleared on death so it can be garbage collected correctly?

(Also just curious as that seems like a useful tool to test memory leaks in general.)

I’ve been dealing with this issue for a while now, and it seems like it had something to do with PlayerGui replication, because when I made a custom script to load StarterGui contents into the PlayerGui through the client instead of the server, the memory going up every time a character died completely stopped. I still don’t know what caused this since the way I’m doing it now is not a real solution and kind of a hack.

Interesting, if this is true it sounds like a bug I reported a while ago


Memory also leaked since last week ago, turns out that studio and player client shows different Memory.

I’ve got around 2GB leaks since this bug occurs on my PC, i thought it was my pc but no error except it only happens on Studio for me.

1 Like

The memory difference between Studio and Player is completely valid, when you run the game in Studio, you are running the server on your machine. The best way to test anything memory related is by Player. + Studio is more intensive to run than Player.

No wonder why my custom death screen I was coding was causing memory leaks. I’m pretty sure it’s LoadCharacter because of the fact the humanoid doesn’t get killed, because my game instead detects when a player value called Death is set to true to cause a custom death system to play which uses LoadCharacter.

Thanks for reporting this bug, hopefully Roblox fixes this as soon as possible!

1 Like

I’ve suspected this happening to both of my games (both Combat-RP games with players constantly resetting) for some time now but I have denied even after refactoring my code to account for memory leaks. Thank you for confirming this was indeed a thing. I’ll likely be changing the way my players “die” to bypass this for now.

1 Like

I can confirm that this is caused by player:LoadCharacter(). I created a test place where it spam loads your character in a loop, and the memory only goes up. Went from 300 to 600 in only a few minutes, it doesn’t appear to have a limit.


As a temporary solution you could use teleporters instead of killing the players.

1 Like

Hello and thank you for the report. We are currently investigating the issue. Thank you for your patience and support :slight_smile:


I have noticed that spamming :LoadCharacter does indeed crash servers. Having remotes that respawn the local player don’t seem to be an issue, but if the loop happens on the server without that network delay, I’ve seen it to become problematic. Not sure if this has anything to do with memory or just connections being spammed, but servers do eventually crash on LoadCharacter loops.

1 Like

I noticed this behavior in one of my private games when I changed characters often (by using LoadCharacter), and because of this I rescripted snippets of code and removed unnecessary connections to see if it would make a difference, although the memory usage kept permanently increasing. I’m glad this has finally been addressed as it’s a major issue.