ThePhD / sol2

Sol3 (sol2 v3.0) - a C++ <-> Lua API wrapper with advanced features and top notch performance - is here, and it's great! Documentation:
http://sol2.rtfd.io/
MIT License
4.16k stars 504 forks source link

Possible memory leak?! #1385

Open An0nyMooUS opened 2 years ago

An0nyMooUS commented 2 years ago
function TEST(i)
   local a = {}
    for i=1, 1024*1024*56 do
        a[i] = 0
     end
     print("a")
end

Calling in C++ code state["TEST"](62);

This code works fine. But, local a is not cleaned after function is called.

to clean up, I need to call state->collectgc(); explicitly. (and it's only cleared if the variable is set to "local")

I don't know if this is lua's behavior, but in my view, after the function is called, everything should be destroyed.

i'm using Lua 5.4.4.

Is this right?

Rochet2 commented 2 years ago

This code works fine. But, local a is not cleaned after function is called. to clean up, I need to call state->collectgc(); explicitly. (and it's only cleared if the variable is set to "local") I don't know if this is lua's behavior,

It is just lua behavior. Any object you create (table, userdata, ...) is destroyed by the GC, and never sooner.

Lua runs the GC when necessary. You have some control over that, but not much. If you require more control over your data, you should maybe use userdata instead and implement whatever logic you need. Maybe expose a function to create vector<int> for example as sol already exposes vector functionality by default, then you can try to maybe call clear on it. https://godbolt.org/z/51ahsn6s5

but in my view, after the function is called, everything should be destroyed.

Just by reading the code above you cannot know if a is referenced from somewhere and if it can be deleted or not. Even if it seems like a local variable, it is entirely possible that it is being referenced from elsewhere as print is a function that could do anything, and it could use debug API to access local variables. You may want to take a look at the garbage collection part of the reference manual: https://www.lua.org/manual/5.4/manual.html#2.5

OrfeasZ commented 2 years ago

You can also look at to-be-closed variables that you can use to emulate the sort of RAII behavior you would expect from C++.


From: Rochet2 @.> Sent: Sunday, July 31, 2022 11:51:53 PM To: ThePhD/sol2 @.> Cc: Subscribed @.***> Subject: Re: [ThePhD/sol2] Possible memory leak?! (Issue #1385)

This code works fine. But, local a is not cleaned after function is called. to clean up, I need to call state->collectgc(); explicitly. (and it's only cleared if the variable is set to "local") I don't know if this is lua's behavior,

It is just lua behavior. Any object you create (table, userdata, ...) is destroyed by the GC, and never sooner.

Lua runs the GC when necessary. You have some control over that, but not much. If you require more control over your data, you should maybe use userdata instead and implement whatever logic you need. Maybe expose a function to create vector for example as sol already exposes vector functionality by defaulthttps://sol2.readthedocs.io/en/latest/containers.html, then you can try to maybe call clear on it. https://godbolt.org/z/51ahsn6s5

but in my view, after the function is called, everything should be destroyed.

Just by reading the code above you cannot know if a is referenced from somewhere and if it can be deleted or not. Even if it seems like a local variable, it is entirely possible that it is being referenced from elsewhere as print is a function that could do anything, and it could use debug APIhttps://www.lua.org/manual/5.2/manual.html#pdf-debug.getlocal to access local variables. You may want to take a look at the garbage collection part of the reference manual: https://www.lua.org/manual/5.4/manual.html#2.5

— Reply to this email directly, view it on GitHubhttps://github.com/ThePhD/sol2/issues/1385#issuecomment-1200497859, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJJBRMKZWJEPE7DBKF2P63VW3ROTANCNFSM55FLM4WA. You are receiving this because you are subscribed to this thread.Message ID: @.***>