LuaJIT, corrupted Lua stack, and getting the global table

Question

I'm currently working to migrate a game (Bitfighter) from Lua 5.1 to LuaJIT 2.0.2. I have gotten it to compile and link appropriately; but, when running the game and actually trying to run a lua script (for a robot), I seem to get a corrupted stack.

The problem occurs when attempting to set the environment for the script - I grab the global environment before making a copy:

lua_pushvalue(L, LUA_GLOBALSINDEX);                      // -- globalEnv

However, when dumping the stack here, the stack has 1 item that is a LUA_TSTRING with a value of NULL (stack was empty beforehand). This had no problems when linking against the normal Lua 5.1 library and the above call correctly pushed the global table onto the stack.

I read that this could mean the stack was corrupted elsewhere and that LuaJIT is less forgiving than the normal VM. I turned on -DLUA_USE_ASSERT and -DLUA_USE_APICHECK compiler flags for LuaJIT, but nothing is being triggered.

Before setting up a script's environment, we do load several scripts into the global environment using lua_pcall as well as set up several other globals using the C API. Could these cause an unknown stack corruption like this?

How can I find the stack corruption? Or, am I missing something else important with LuaJIT?

Answer 1

After some more trial-and-error, I found that our build system was pulling in Lua headers from a different Lua distribution before those of LuaJIT's. This was causing the corrupt stack.

After removing the hard-coded #include directives to the old distribution, and properly putting LuaJIT's headers on the compile path, I was able to successfully manipulate the global stack again.

Answer 2

Turn on assertions for Lua and see what happens. It is often the case that you get away with some stuff in Lua that LuaJIT is not so lenient about. Turning assertions on for Lua will help you isolate the problem (is it your code - most likely or LuaJIT itself)