Wrappers are flawed (gmod internal?)

[ghost]

The current wrapping system creates two tables, sensitive2sf and sf2sensitive, these tables have weak values and keys respectively, because of the way Starfall does caching by doing sensitive2sf[value] = tbl (line 260 in sflib.lua) I believe that the two weak tables 'reinforce' each other, thus never marking wrapped objects for garbage collection properly. (when they should)

It seems that this is most noticeable when using structs that have a 'non-absolute' index, such as, you can have two or more keys that are Vector( 1, 1, 1 ) in a table, as those are userdata values with each their own memory address; but it's not to say that basically everything is memory-leaked with the current code, but it isn't as noticeable with some wrapped objects due to their 'absolute' index, making it so that the cache value is overridden. (for example entity wrapping).

At first I thought this could not have possibly been the issue, how can it be this flawed?
But then I tried commenting out line 260 in sflib.lua (--sensitive2sf[value] = tbl) and setting the __mode of sf2sensitive to kv, and all the memory-related issues disappeared.

An example of this flaw in action:

if not SERVER then return end

hook.add( "think", "mem_overflow", function()
    for i=1, 4096 do
        v=Vector( 1, 2, 3 )
    end
end )

P.S. Excuse my incorrect terminology.

EDIT: This seems to be an internal issue? The tables are printing blank but garbage isn't collected properly.

P.P.S Please check the issue report on thegrb93/StarfallEx before asking questions to avoid asking ones that have already been asked/answered.

[awilliamson]

@ThatOneCheetah Thanks for bringing this up! Will definitely look into this. Didn't see your reference before, but I believe this could be because internally engine related stuff is being cleaned up - causing Lua refs to stop. However, non-engine stuff like Colour, Vector, and anything which just encapsulates basic lua tables isn't being garbage collected properly ( stray references somewhere??? ).

I've seen memory issues in the past with screens, but couldn't exactly reproduce it nicely. Perhaps this was because of the complex programs running on them.

Certainly feel free to suggest any changes, but please be cautious, as knock-on effects may not be known without significant testing etc. Also, please note not to get thegrb's repository confused with our own, there are valid reasons as to why he was previously banned from participating in this organisation.

Feel free to keep this issue updated with anything new you find, or to discuss any potential solutions you believe would be suitable.

EDIT - Just seen you P.P.S. I am not familiar with whatever changes thegrb has seen 'fit' to include in his clone, therefore any questions there may be based on false assumptions, or incorrect code. Therefore, apologies if any questions are repeated, but they must be strictly in relation to this codebase.

[ghost]

Confirmed GLua issue.

test = {}
hook.Add( "Think", "MemTest", function()
    for i=1, 4096 do
        test[Vector(1,1,1)] = true
    end
end )

timer.Simple( 5, function()
    hook.Remove( "Think", "MemTest" )
    for k, _ in pairs( test ) do test[k] = nil end
    for i=1, 16 do collectgarbage() print( "GC"..i..": ", math.Round(collectgarbage( "count" )/1024, 2) .. " MB" ) end
end )

Seems to show the same leaks.

[Jazzelhawk]

Pretty sure this can be closed now right?