Re: error when loading strict.lua

["Dirk Feytons" <dirk.feytons@...>]

On 9/13/07, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
> > (I patched luaL_newstate())
>
> Can you show us this then? Can you try it with plain, unpatched Lua?

Owkey, I have some more info now. I managed to simplify my setup a bit
and get a debugger attached. The error isn't triggered when loading
strict.lua but later on when I want to run some actual Lua code. To
give you some context: I'm integrating CGILua from the Kepler project
with our webserver. Everything was working fine before I added the
loading of strict.lua.

When a HTTP request comes in my LuaHandler gets called. There I have
the following code:

[...some server related setup code...]
lua_State* L = luaL_newstate();
luaL_openlibs(L);
luaL_dofile(L, "strict.lua"));    // only this was added
[...load the SAPI implementation for CGILua with luaL_register()...]
[...load CGILua itself with luaL_dofile()...]
if (luaL_dostring(L, "cgilua.main()") == 0)   // <-------- boom!
    [...everything OK, flush output to client...]
else
    [...error; return HTTP code 500: internal server error...]
[...cleanup...]

The stack overflow is triggered from the execution of the
'cgilua.main()' function. The stack looks like follows (don't trust
the linenumbers, files were patched in the switch to 'long' instead of
double for LUA_NUMBER):
[...webserver frames...]
#801 0xb7ee3610 in LuaHandler::run () at luahandler.cpp:450
#800 0xb7ee4ff9 in lua_pcall () at lapi.c:817
#799 0xb7ee7dc7 in luaD_pcall () at ldo.c:461
#798 0xb7ee7032 in luaD_rawrunprotected () at ldo.c:116
#797 0xb7ee4f71 in f_call () at lapi.c:796
#796 0xb7ee7ae3 in luaD_call () at ldo.c:377
#795 0xb7ef212d in luaV_execute () at lvm.c:472
#794 0xb7ef10b8 in luaV_settable () at lvm.c:170
#793 0xb7ef0dba in callTM () at lvm.c:122
#792 0xb7ee7ae3 in luaD_call () at ldo.c:377
#791 0xb7ef1ee3 in luaV_execute () at lvm.c:451
#790 0xb7ef0efc in luaV_gettable () at lvm.c:143
#789 0xb7ef0c88 in callTMres () at lvm.c:106
#788 0xb7ee7ae3 in luaD_call () at ldo.c:377
#787 0xb7ef1ee3 in luaV_execute () at lvm.c:451
#786 0xb7ef0efc in luaV_gettable () at lvm.c:143
#785 0xb7ef0c88 in callTMres () at lvm.c:106
#784 0xb7ee7ae3 in luaD_call () at ldo.c:377
#783 0xb7ef1ee3 in luaV_execute () at lvm.c:451
#782 0xb7ef0efc in luaV_gettable () at lvm.c:143
[...]
#5  0xb7ef0c88 in callTMres () at lvm.c:106
#4  0xb7ee7ae3 in luaD_call () at ldo.c:377
#3  0xb7ef1ee3 in luaV_execute () at lvm.c:451
#2  0xb7ef0efc in luaV_gettable () at lvm.c:143
#1  0xb7ef0c88 in callTMres () at lvm.c:106
#0  luaD_call () at ldo.c:372

Any idea what triggers this loop? Should I call cgilua.main() in a
different way? If so, why did it work before?

Thanks,
-- 
Dirk