Ravi bug related to setting of L->top in OP_RETURN

[Dibyendu Majumdar <mobile@...>]

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