Reproduction Steps
You can reproduce this issue by running this snippet in the command bar while in Play Solo:
local StarterGui = game:GetService("StarterGui")
local coreGuiType = Enum.CoreGuiType.All
for i = 1,10^2 do
StarterGui:SetCoreGuiEnabled(coreGuiType, false)
task.wait()
StarterGui:SetCoreGuiEnabled(coreGuiType, true)
task.wait()
end
Once you run that, you should notice the Gui and LuaHeap memory categories rising in the developer console. You can even reproduce it without the for loop, but it’s more noticeable the more you do it. It seems to only rise when enabling one of the core guis after it has been disabled.
Expected Behavior
When disabling a core gui and re-enabling it, I’d expect the Gui and LuaHeap memory categories to either stay the same or only momentarily go up.
Actual Behavior
When disabling a core gui and re-enabling it, the Gui and LuaHeap memory categories rise and don’t lower afterwards.
Does it keep going up consistently as you increase the number of iterations? Does it lead to an out-of-memory error eventually?
More memory being used is not necessarily indicative of a memory leak. It could just be that the memory is not being freed up if not necessary to do so (e.g. a reasonable amount of memory is still available), or it’s keeping it allocated in case it is needed in the future, since deallocation is not free.
It does keep on going up consistently as the number of iterations is increased. It doesn’t lead to an error, but it does crash the client after only a minute or two. You can check it out here:
I tried the same exact place on my phone and it seemed to take a bit longer for it to crash. This leads me to believe that it somehow involves whether or not certain core guis are immediately visible when being re-enabled. Here’s what it looked like right before Roblox crashed on my phone:
Thank you for filing this issue. I’m trying to understand the real-life implications of this issue. Can you give me a few examples when this would come up?
Not the OP but this issue is affecting me as well. Some of my UI elements take up the full screen, and when this happens I disable unnecessary CoreGui’s (like the chat/leaderboard). To do this, every time the player open/closes that frame I call SetCoreGuiEnabled, which is where the memory leak arises.
So in my game I have a cinematic mode button that allows the users to toggle all the core guis from being visible (as well as the guis created by me) so they can take screenshots. I also disable all the core guis during certain interactions that require the player to momentarily focus on certain elements on the screen rather than chat, the player list, and their backpack.
The only reason why I noticed this issue in the first place is because these scenarios occur a lot inside my game.
The only update I have is this: There is nothing “obviously wrong” in the code. The EmotesMenu and the PlayerList seem to contribute to most to the memory. I wonder if checking if they are visible before hiding and showing would help in the short term. Also, this looks to be happening with all other GUIs, for example showing and hiding the Developer Console also uses a some memory that is not freed up right away.
