[Solved] Memory Leak in only two lines

[OnlyFails]

Thanks everyone for the help, I wasn't expecting such an amazing response time!
I was just worried because I usually program in C++ and I handle my own garbage collection, I guess that caused some trust issues when moving to easier, more user friendly languages like Lua.

If you have a leak of few mb per second in your code it is not caused by the 2 lines you provided.

Code: Select all

for i=1,10000 do
	love.graphics.setColor(255, 255, 255, 255)
	love.graphics.rectangle("fill", 10, 10, 100, 100)
end

Some things that can cause higher memory upkeep:

Userdata - creating new userdata every frame. This includes image objects among other things.

Tables - all inaccessible tables are eventually collected, if you create a lot of them per frame it can add up and the garbage collector will spend a lot of time keeping up and you will notice higher memory upkeep.

Note neither of these are leaks since the garbage collector takes care of most dumbassery you throw at it, including memory islands. In case you're working with love.physics or other framework modules it is possible to make the collector cry and hide things inside userdata objects which it will not clean up, such as the setUserData() method in some physics objects.

Unless your program crashes due to insufficient memory over time, it's likely your code just produces a lot garbage on the side.

Anyway I see what you mean by the garbage collector letting memory usage pile up before clearing it all,
I let the program run a bit (and using collectgarbage( 'collect' ) after every draw cycle) and it never went over a specific amount of MB of RAM.

I am using userData in the love physics module so I might be misusing it probably, are there any basic house keeping tips I should know about with using them? How are they any different from storing a table as a member inside any other table?

[Azhukar]

I am using userData in the love physics module so I might be misusing it probably, are there any basic house keeping tips I should know about with using them?

Set userdata to nil before destroying an object. You need to explicitly pass it nil otherwise it will error.

How are they any different from storing a table as a member inside any other table?

I don't know the inner workings but I do know that tables assigned as userdata of destroyed objects will not get collected. You can test this out by using weak tables to keep a weak reference to your userdata table, then calling collect garbage after the object with userdata is destroyed.

[slime]

The reference to the userdata of a Fixture or Body is removed when that Fixture or Body is garbage collected. Once that happens, the (no longer) referenced user data is free to be garbage collected itself if there are no other Lua-side references to it (although, like all garbage collection in Lua, it may take some time.)

[bartbes]

Also, for those of you expecting it gets collected right after nilling it: it doesn't.
For those expecting it to get collected after nilling and calling collectgarbage: it doesn't.
Lua's garbage collector is such that it requires two complete runs before userdata is collected, after the first run its destructor get called (so typically most memory gets freed then), and it becomes unreachable, after the second run it gets destroyed itself.
Note though, that due to the way memory allocation works, it's very hard to see this happen accurately, and if memory usage is low, you might not see it drop at all.

[OnlyFails]

I am using userData in the love physics module so I might be misusing it probably, are there any basic house keeping tips I should know about with using them?

Set userdata to nil before destroying an object. You need to explicitly pass it nil otherwise it will error.

How are they any different from storing a table as a member inside any other table?

I don't know the inner workings but I do know that tables assigned as userdata of destroyed objects will not get collected. You can test this out by using weak tables to keep a weak reference to your userdata table, then calling collect garbage after the object with userdata is destroyed.

Really great information here! Thanks for the help Azhukar

[Ref]

Set userdata to nil before destroying an object. You need to explicitly pass it nil otherwise it will error.

Not my experience with deleting images created from userdata!
Can repeatedly recreate an image from the same (slightly modified) userdata.