# operator will cause leak

[hello_man]

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));

[hello_man]

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

[Lourival Vieira Neto]

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"

[hello_man]

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 .

[Lourival Vieira Neto]

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!