Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

# operator will cause leak #49

Open
trialman opened this issue Jun 12, 2023 · 4 comments
Open

# operator will cause leak #49

trialman opened this issue Jun 12, 2023 · 4 comments
Assignees

Comments

@trialman
Copy link

trialman commented Jun 12, 2023

use # operator not only cause gc problem but also overwrite data in memory and cause kernel panic .

collectgarbage("collect")
before = collectgarbage("count");
for i = 1, 10000 do
    local tb= {};
    for j = 1, 100 do
        tb[j]  ={ k=1}
    end

    -- gc not work
    --local i = #tb

    --- gc not work
    --for i = 1, #tb do
    --
    --end
    
    ---- gc not work
    --local tb = {}
    --for i = 1, 100 do
    --    tb[i]="aa"
    --end
    --local i = #tb



    
    -- gc work fine
    --local tb2={ {a=1}}
    --local i = #tb2

    ---- gc work fine
    --local tb = {{k=1},{k=1},{k=1},{k=1},{k=1},{k=1},{k=1},{k=1},{k=1},{k=1}}
    --local i = #tb



    ---- gc work fine
    --local tb = {"a","b","c","a","b","c","a","b","c","a","b","c"}
    --local i = #tb


    ---- gc work fine
    --local str = "adsfafas"
    --local len = #str

    ---- gc work fine
    --for i = 1, 100 do
    --
    --end
    --
    ----gc work fine
    --for i, v in pairs(tb) do
    --
    --end

end
for i = 1, 1000 do
    collectgarbage("collect")
end
after = collectgarbage("count");
print(string.format("gc before: %s after: %s", before, after));

image

@trialman trialman changed the title if use # operator will cause leak # operator will cause leak Jun 12, 2023
@lneto lneto self-assigned this Jun 12, 2023
@trialman
Copy link
Author

i figuare out the problem . UINT_MAX is patched in limits.h , but the compiler use standard limits.h instead T_T.

@lneto lneto reopened this Jun 14, 2023
@lneto
Copy link
Contributor

lneto commented Jun 14, 2023

hi @trialman, thanks for the report. Did you change anything? Is it still happening? I think I've found the reason the compiler ins't using the correct limits.h; can you try this patch?

diff --git a/lctype.h b/lctype.h
index c00e6249..864e1901 100644
--- a/lctype.h
+++ b/lctype.h
@@ -31,9 +31,7 @@

 #if !LUA_USE_CTYPE     /* { */

-#ifndef _KERNEL
 #include <limits.h>
-#endif /* _KERNEL */

 #include "llimits.h"

diff --git a/ltable.c b/ltable.c
index 509c0e7b..e51e5750 100644
--- a/ltable.c
+++ b/ltable.c
@@ -23,10 +23,8 @@
 ** Hence even when the load factor reaches 100%, performance remains good.
 */

-#ifndef _KERNEL
 #include <math.h>
 #include <limits.h>
-#endif /* _KERNEL */

 #include "lua.h"

@trialman
Copy link
Author

Sorry , I didn't describe clearly . As the phone manufactor add restrictions to prevent loading dynamic module , I have to build lunatik into kernel . I am not that familiar with kernel compiling , so I can only guess the include dir search order cause this . I just roughly copy the macro in limts.h to ltable.c and then eveything goes well .

@lneto
Copy link
Contributor

lneto commented Jun 17, 2023

hi @trialman, thanks for the clarification.. I believe this affects you only due to cross-compiling.. can you try out the master or the latest release? It is supposed to be fixed there now (although, I couldn't reproduce the issue on my end). Please, let me know so I can close this issue.

BTW, can you share more information about your use case and how you end up with such test case? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants