lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I do not have experience with gc modes, so my testing may be misguided or overly limited

> The default mode in 5.4 is generational. You might change it to incremental
really? Because the first return value from lua_gc is 11 (LUA_GCINC) and not LUG_GCGEN. This series of changing the gc mode passes all the asserts:

  lua_State* _state = luaL_newstate();
  int prev;
  prev = lua_gc(_state, LUA_GCGEN);
  assert(prev == LUA_GCINC);
  prev = lua_gc(_state, LUA_GCINC, 0, 344, 1);
  assert(prev == LUA_GCGEN);
  prev = lua_gc(_state, LUA_GCINC, 0, 344, 1);
  assert(prev == LUA_GCINC);
  prev = lua_gc(_state, LUA_GCGEN);
  assert(prev == LUA_GCINC);
  prev = lua_gc(_state, LUA_GCINC, 0, 344, 1);
  assert(prev == LUA_GCGEN);

the above gc mode switches was just a test
I removed the test code, and tested with LUA_GCINC
Bisecting on the step value, keeping pause (=0) and mult set to 1, i find that i can get a crash at >= 344

  lua_gc(_state, LUA_GCINC, 0, 344, 1);

larger step values seem to increase the gc bug chance, with some variance still

again, the bug repro's in gen mode too



to check that.



One more question: can you be sure the __gc of a table is being called

twice? For what I saw in your code (the first version you sent), the

problem of destroying the same userdata twice could be caused by

some bug in the weak table, if it returned the same userdata for

two different tables. That is, when cleaning the weak table from a

deleted key, it might get corrupted and then could return a wrong

value in a future query.



Again, many thanks,



-- Roberto

_______________________________________________

lua-l mailing list -- lua-l@lists.lua.org

To unsubscribe send an email to lua-l-leave@lists.lua.org

_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org