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

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

[Dibyendu Majumdar]

Apologies - wrong list!

Please ignore.

On 2 August 2015 at 10:48, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> 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_pocall returns non zero b. So this
> then causes subsequent code to clobber the stack.
>
> Thanks and Regards
> Dibyendu

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

[Dibyendu Majumdar]

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_pocall returns non zero b. So this
then causes subsequent code to clobber the stack.

Thanks and Regards
Dibyendu