Ravi bug related to setting of L->top in OP_RETURN
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Ravi bug related to setting of L->top in OP_RETURN
- From: Dibyendu Majumdar <mobile@...>
- Date: Sun, 2 Aug 2015 10:51:02 +0100
Hi
I am investigating a particularly difficult bug related to setting of
L->top, and would appreciate some insight on what L->top should be
when a function returns via OP_RETURN.
The Lua code does following in OP_RETURN:
int b = GETARG_B(i);
if (cl->p->sizep > 0) luaF_close(L, base);
b = luaD_poscall(L, ra, (b != 0 ? b - 1 : L->top - ra));
if (!(ci->callstatus & CIST_REENTRY)) /* 'ci' still the called one */
return; /* external invocation: return */
else { /* invocation via reentry: continue execution */
ci = L->ci;
if (b) L->top = ci->top;
lua_assert(isLua(ci));
lua_assert(GET_OPCODE(*((ci)->u.l.savedpc - 1)) == OP_CALL);
goto newframe; /* restart luaV_execute over new Lua function */
}
It is not clear to me why in the external invocation case, if
following code is not executed:
ci = L->ci;
if (b) L->top = ci->top;
A related question is what is the meaning of the return value from
luaD_poscall() - it seems to be a signal for L-top to be reset to
ci->top, but I am not sure I understand when this happens.
The bug in Ravi is caused under following conditions:
JITed code invokes Lua function via luaV_execute() in a local variable
declaration:
local var = func(a,b)
Since CIST_REENTRY is not set in this case (whereas it would be if
interpreted Lua code had called the function) upon return, L->top is
not reset to ci->top although luaD_poscall returns non zero b. So this
then causes subsequent code to clobber the stack.
Thanks and Regards
Dibyendu