[Tarantool-patches] [PATCH v2 luajit 23/30] test: disable PUC Lua test for fast function name
Igor Munkin
imun at tarantool.org
Mon Apr 12 12:36:41 MSK 2021
Sergey,
On 07.04.21, Sergey Kaplun wrote:
> Igor,
>
> On 07.04.21, Igor Munkin wrote:
> > Sergey,
> >
> > On 07.04.21, Sergey Kaplun wrote:
> > > Igor,
> > >
> >
> > <snipped>
> >
> > > > > > > diff --git a/test/PUC-Lua-5.1-tests/errors.lua b/test/PUC-Lua-5.1-tests/errors.lua
> > > > > > > index cf24e40..af776a7 100644
> > > > > > > --- a/test/PUC-Lua-5.1-tests/errors.lua
> > > > > > > +++ b/test/PUC-Lua-5.1-tests/errors.lua
> > > > > > > @@ -105,9 +105,13 @@ while 1 do
> > > > > > > insert(prefix, a)
> > > > > > > end]], "global 'insert'")
> > > > > > >
> > > > > > > -checkmessage([[ -- tail call
> > > > > > > - return math.sin("a")
> > > > > > > -]], "'sin'")
> > > > > > > +-- LuaJIT: Can't determine bytecode position for non Lua functions
> > > > > > > +-- (in particular for fast functions) and, therefore, detect fast
> > > > > > > +-- function names for errors in tail calls.
> > > > > >
> > > > > > This is kinda gibberish. I've tried the following snippets and can't
> > > > > > understand what do you mean by this comment.
> > > > > >
> > > > > > | $ luajit -e 'function q(a) return math.sin(a) end q("a")'
> > > > > > | luajit: (command line):1: bad argument #1 to 'q' (number expected, got string)
> > > > > > | stack traceback:
> > > > > > | [C]: in function 'q'
> > > > > > | (command line):1: in main chunk
> > > > > > | [C]: at 0x5610e8497eb0
> > > > > > | $ luajit -e 'loadstring("return math.sin([[a]])")()'
> > > > > > | luajit: (command line):1: bad argument #1 to '?' (number expected, got string)
> > > > > > | stack traceback:
> > > > > > | [builtin#43]: at 0x7fc0f807ad10
> > > > > > | (command line):1: in main chunk
> > > > > > | [C]: at 0x55c1e85c7eb0
> > > > > >
> > > > > > I understand the first result. The second result surprised me, but I've
> > > > > > never investigated how loadstring call works (it looks like specifics of
> > > > > > VARG frame, but this is a wild guess). But neither of them fits your
> > > > > > explanation. The root cause is the same: callee uses caller frame, since
> > > > > > caller doesn't need it anymore. Could you please clarify yours?
> > > > >
> > > > > This is not about `loadstring()` at all:
> > > > >
> > > > > | luajit -e 'return math.sin"a"'
> > > > > | luajit: bad argument #1 to '?' (number expected, got string)
> > > > > | stack traceback:
> > > > > | [builtin#43]: at 0x7f7c2ca6dbe0
> > > > > | [C]: at 0x558b0cd4cec0
> > > > >
> > > > > The guest frame is looked like the following (when the error thrown):
> > > > > | 0x40001938 [ ] VALUE: string "number expected, got string" @ 0x40008380
> > > > > | 0x40001930 [ B ] VALUE: string "a" @ 0x40008250
> > > > > | 0x40001928 [ ] FRAME: [CP] delta=3, fast function #44
> > > > >
> > > > > When LuaJIT tries to detect function's name it determines bytecode
> > > > > position first, via `debug_framepc()`. But it can't determine bytecode
> > > > > position for non-Lua functions:
> > > >
> > > > What? Both luajit-gdb.py and LuaJIT itself reports the fast function ID
> > > > and this is its name.
> > >
> > > Yes, what is your question about?
> >
> > Then what's the problem with name resolving?
>
> As I said before for tailcall there is no creation of additional Lua
> frame. Without it guest frame is looks like the following:
>
> | 0x40001950 [ T ]
> | 0x40001948 [ ] VALUE: string "number expected, got string" @ 0x40008380
> | 0x40001940 [ B ] VALUE: string "a" @ 0x40008280
> | 0x40001938 [ ] FRAME: [LP] delta=1, fast function #44
> | 0x40001930 [ ] FRAME: [V] delta=1, Lua function @ 0x40008248, 0 upvalues, "=(command line)":0
> | 0x40001928 [ ] FRAME: [CP] delta=3, Lua function @ 0x40008248, 0 upvalues, "=(command line)":0
>
> `err_argmsg()` function uses `lj_debug_funcname()`, which uses
> `debug_framepc()`, which can't get bcpos required for function prototype
> detection (see explanation with code sources above). So, LuaJIT can't
> detect fast function names for tailcalls on C frame.
And *this* is finally a good explanation of the issue you resolved here.
Please adjust the original comment considering the wording above. After
this change made, the patch LGTM, thanks!
>
> >
> > >
> > > >
> > > > >
> > > > > | if (!isluafunc(fn)) { /* Cannot derive a PC for non-Lua functions. */
> > > > > | return NO_BCPOS;
> > > > >
> > > > > >
> > > > > > > +-- The test is disabled for LuaJIT.
> > > > > > > +-- checkmessage([[ -- tail call
> > > > > > > +-- return math.sin("a")
> > > > > > > +-- ]], "'sin'")
> > > > > > >
> > > > > > > checkmessage([[collectgarbage("nooption")]], "invalid option")
> > > > > > >
> >
> > <snipped>
> >
> > >
> > > --
> > > Best regards,
> > > Sergey Kaplun
> >
> > --
> > Best regards,
> > IM
>
> --
> Best regards,
> Sergey Kaplun
--
Best regards,
IM
More information about the Tarantool-patches
mailing list