How do you really tell if your game has a memory leak?

[BrotSagtMist]

Its interesting that at doesnt crash at least.

Your understanding of a bug seems to be wildly different than mine.
Nothing of this has anything to do with lua or löve or how they work.
I piece of code, regardless of its language, that uses ram for no reason is buggy.
The type of bug is a memory leak.

[marclurr]

I've always thought of a memory leak as memory consumption that can't be recovered, similar to others in the thread. In the case of a GC'd language haemorrhaging memory I've always just considered this wasteful programming. Your example is quite illustrative as to why you can't just ignore memory consumption even in a GC'd language as they're not necessarily configured to handle your use case out of the box, and can lead to a crash in some circumstances.

[pgimeno]

Its interesting that at doesnt crash at least.

And that's my point: there comes a point where the garbage generation rate equals the garbage collection rate, and past that point, memory stops growing. The problem is the number of objects generated at that point, and the space occupied by each. The same program using love.image.newImageData() with a big enough size instead of love.graphics.newFont(), would probably lead to a crash even in a 64 GB machine.

Your understanding of a bug seems to be wildly different than mine.
Nothing of this has anything to do with lua or löve or how they work.
I piece of code, regardless of its language, that uses ram for no reason is buggy.

If Love's scripting language was CPython, the very same program would not "use ram for no reason". Python is a garbage-collected language as well, but CPython has reference counting as a first-front garbage collection strategy, and for the cases where that one fails, there's a second strategy similar to Lua's. With reference counting, objects are freed as soon as they stop having anything referencing them, so each old font would be freed immediately, before the next statement's execution.

This proves that it does have everything to do with the language, because for the same code, there's another language where this does not happen. I don't consider it a bug in Löve, but a quirk of Lua that Lua programmers need to be aware of, and affecting Löve programmers, as well as programmers in any other framework that uses Lua where big objects can be created, where the size of said objects is not visible to Lua.

The type of bug is a memory leak.

By your definition, either it is a memory leak in your computer but not in mine, or every Löve program has a memory leak bug. Neither of these makes sense to me.

[slime]

In case anyone isn't aware, the reason love objects (or anything not entirely owned by Lua) don't get collected "quick enough" to avoid high memory use situations when you spam creation of them, is because Lua isn't able to know how much memory the object actually takes. love objects don't use Lua memory allocations for the actual object, only the proxy. And graphics objects also use VRAM in addition to regular memory.

So Lua thinks a love object is just a few bytes because that's the size of the Lua proxy allocation, regardless of how much actual RAM or VRAM is used - which means it doesn't prioritize garbage collecting it like it would if you had a massive table or string.

That being said, like pgimeno says the fact that collections happen Sometime In The Future instead of immediately means the high water mark of allocated-and-waiting-to-be-freed memory can increase beyond what you might expect when using any garbage-collected language, if you have bad code that has tons of temporary allocations. You can also cause memory fragmentation by doing that. This is one of the big reasons why Lua has a table.concat function instead of needing you to write a loop of concatenations - the latter would cause tons of temporary allocations that are slow, increase memory use by a lot, and increase memory fragmentation.

Not needing to explicitly free allocations you've made doesn't absolve your responsibility to write code that uses those allocations wisely.