Do you get a segfault or equivalent? If so, that's a bug — please report
it on the LuaJIT issue tracker at https://github.com/LuaJIT/LuaJIT/issues.
If instead you get a panic, that is a known bug that will hopefully be
fixed eventually, but which will likely not be fixed in the near future.
You can prevent the process from exiting by setting a custom panic function
that never returns, but note that the lua_State must not be used afterwards
and that you are likely to leak resources.
On Feb 12, 2017 6:11 PM, "Mars Arkane" <marsarkane@xxxxxxxxx> wrote:
Another problem I just noticed is that returning a null pointer from the
allocation function, when too much memory is in use, crashes the program
with LuaJit =/ This too works fine with Lua.
2017-02-12 23:16 GMT+01:00 Mike Pall <mikelj-1702@xxxxxxx>:
Mars Arkane wrote:
[...] I simply set that function with lua_setallocf [...]
Umm ... so you're using luaL_newstate() and then later on setting
lua_setallocf? That's not a good idea.
A state created by luaL_newstate() already has some memory
allocated with the default allocator. These memory blocks will
eventually be passed to your allocator for freeing; at the latest
during lua_close(). It's most certainly not prepared to deal with
foreign memory blocks.
Because detecting foreign memory blocks is non-trivial, check out
lua_newstate() ('lua_', not 'luaL_') for a better solution.
The other restriction is that the (current default) x64 build has
special needs regarding the allocated memory areas, which your
allocator most probably doesn't fulfill. Turn on assertions when
building LuaJIT to catch this (and other issues).
--Mike
