Whenever string.rep is called it causes a small "fake" memory leak. What I mean by "fake" is, the process doesn't actually leak memory, but Lua thinks it does. In other words, collectgarbage("count") and gcinfo() return wrong results.
I've only tested string.rep so far, but there's a decent chance other functions might be affected as well. I think there's a good chance it's not actually an issue with string.rep itself but instead with how memory usage is tracked altogether.
To Reproduce
Open the built-in lua interpreter and run the following snippet:
old = collectgarbage("count") for i = 1, 1000000 do (" "):rep(1000) end print(collectgarbage("count") - old)
This runs a whole lot of calls to string.rep without storing the resulting string anywhere so they can be gc'ed pretty much immediately and then prints the difference in total used memory in KB.
Expected behavior
After running the snippet above I'd expect collectgarbage("count") and gcinfo() to return close to zero bytes, and yet they return almost a full GB for me, although the exact value varies. (And yes, if you execute it multiple times and look at the old variable, the actual result does increase GB by GB as well.) When inspecting the process itself (using the Windows Taskmanager in my case) it shows that it stays at ~8MB the entire time, so there is no actual memory leak.
Environment
OS: Windows 10 (it is also reproducible in the web version though)
Describe the bug
Whenever
string.repis called it causes a small "fake" memory leak. What I mean by "fake" is, the process doesn't actually leak memory, but Lua thinks it does. In other words,collectgarbage("count")andgcinfo()return wrong results.I've only tested
string.repso far, but there's a decent chance other functions might be affected as well. I think there's a good chance it's not actually an issue withstring.repitself but instead with how memory usage is tracked altogether.To Reproduce
Open the built-in
luainterpreter and run the following snippet:This runs a whole lot of calls to
string.repwithout storing the resulting string anywhere so they can be gc'ed pretty much immediately and then prints the difference in total used memory in KB.Expected behavior
After running the snippet above I'd expect
collectgarbage("count")andgcinfo()to return close to zero bytes, and yet they return almost a full GB for me, although the exact value varies. (And yes, if you execute it multiple times and look at theoldvariable, the actual result does increase GB by GB as well.) When inspecting the process itself (using the Windows Taskmanager in my case) it shows that it stays at ~8MB the entire time, so there is no actual memory leak.Environment