Memory leak: Modulescripts never Garbage Collected after Destroy()'d and all references are removed

Reproduction Steps

I’ve created a test place to demonstrate this memory leak: (2) module GC test - Roblox

Basically, there’s a serverscript in ServerScriptService that is replicating a module over to the client constantly, a localscript in StarterPlayerScripts that is destroying all of the modules it receives.

Join the game and watch the Clientside Script memory (ignore server side, since I’m only deleting the modules on the client) increase at a constant rate as the new modulescripts flow in, but never go down even though the modulescripts are being destroyed and have no references to them that would prevent garbage collection.


^ Screenshot shows script memory rising

I added a button you can click to stop the server from sending over more modulescripts, so you can see that the deleted modulescripts are never cleared from Script memory clientside.


^ Observe the flat line on Script memory after no new modulescripts were replicated to the client, and all previously replicated modulescripts have been Destroy()'d and have no references to them (so they should be garbage collected, but aren’t)

[Sidenote: In my localscript code for deleting the modulescripts, I commented out a line where I require() the modulescript. If you uncomment that line, you can see that not only will Script memory rise without falling, but LuaHeap will also rise without falling. Initially, I encountered this issue through a memory leak in my game where LuaHeap kept rising, I narrowed it down to my system of loading in modulescripts packed with map data (the tables of Vector3’s you see inside the test modulescript I’m using). That’s how I came across this issue of modulescripts not being garbage collected, and I found that you can better observe this behavior through Script memory, since LuaHeap has more variability. But LuaHeap is also important to this issue.]

Expected Behavior

Memory should be cleared for ModuleScripts that are destroyed and have no references to them (they should be garbage collected)

Actual Behavior

Engine memory leak – Script memory (and LuaHeap if module is required) will rise but never fall when modulescripts are sent to the client and later deleted.

Issue Area: Engine
Issue Type: Performance
Impact: Very High
Frequency: Constantly

10 Likes

Hello and thank you for the report. I’m seeing this issue in a similar setup.

4 Likes

We have an issue right now where ModuleScript instances that are only destroyed on the client without a corresponding Destroy call on the server will remain in memory.
We don’t have a timeline for a fix of this issue right now.

As a work-around, try destroying the scripts on the server side when data is no longer required or use RemoteEvent to send data to clients instead.

4 Likes

Any news when the issue will be patched?

I can’t promise when this will be fixed, but we have people who started working on it recently.
It seems that the issue affects more than just scripts, but they hold much more memory than other instance types.

5 Likes

Do you have any ETA when it will be patched?

Just checked, no progress on this yet. I’ll raise the question about this internally one more time.

3 Likes

Thank you for your information and a very fast answer.

Still no news about that , sadly