* [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
@ 2023-08-15 14:25 Sergey Kaplun via Tarantool-patches
2023-08-16 12:25 ` Maxim Kokryashkin via Tarantool-patches
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Sergey Kaplun via Tarantool-patches @ 2023-08-15 14:25 UTC (permalink / raw)
To: Maxim Kokryashkin, Sergey Bronnikov; +Cc: tarantool-patches
From: Mike Pall <mike>
Reported by Sergey Kaplun.
(cherry-picked from commit caf7cbc57c945f7b68871ad72abafb2b6e6fb7f5)
Assume, we have the following Lua code:
| local _
| for _ in (nil):foo() do end
The first part of the bytecode emitted for it is the following:
| 0001 KNIL 0 1
| 0002 MOV 2 1
| 0003 TGETS 1 1 0 ; "foo"
| 0004 CALL 1 4 2
The `0001 KNIL` is a result of merging two `KPRI` instructions: one for
the local variable, one for the slot with `nil` object. During parsing in
`predict_next()` the second `MOV` bytecode is examined to set `pairs` or
`next` local variable. But, as far as it moves `nil` value, that isn't
an actual variable, so it has no the name this leads to the crash.
This patch adds the check to be sure that `RD` in the `MOV` bytecode is
an actual variable.
Sergey Kaplun:
* added the description and the test for the problem
Part of tarantool/tarantool#8825
---
Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1033-fix-parsing-predict-next
PR: https://github.com/tarantool/tarantool/pull/8987
Related issues:
* https://github.com/LuaJIT/LuaJIT/issues/1033
* https://github.com/tarantool/tarantool/issues/8825
src/lj_parse.c | 1 +
.../lj-1033-fix-parsing-predict-next.test.lua | 30 +++++++++++++++++++
2 files changed, 31 insertions(+)
create mode 100644 test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
diff --git a/src/lj_parse.c b/src/lj_parse.c
index 3f6caaec..420b95cb 100644
--- a/src/lj_parse.c
+++ b/src/lj_parse.c
@@ -2532,6 +2532,7 @@ static int predict_next(LexState *ls, FuncState *fs, BCPos pc)
cTValue *o;
switch (bc_op(ins)) {
case BC_MOV:
+ if (bc_d(ins) >= fs->nactvar) return 0;
name = gco2str(gcref(var_get(ls, fs, bc_d(ins)).name));
break;
case BC_UGET:
diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
new file mode 100644
index 00000000..624344eb
--- /dev/null
+++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
@@ -0,0 +1,30 @@
+local tap = require('tap')
+local test = tap.test('lj-1033-fix-parsing-predict-next')
+
+test:plan(3)
+
+local res_f = loadstring([[
+-- This local variable is necessary, because it emits `KPRI`
+-- bytecode, with which the next `KPRI` bytecode will be merged.
+--
+-- The resulting bytecode is the following:
+--
+-- 0001 KNIL 0 1
+-- 0002 MOV 2 1
+-- 0003 TGETS 1 1 0 ; "foo"
+-- 0004 CALL 1 4 2
+--
+-- This MOV don't use any variable value from the stack, so the
+-- attempt to get the name in `predict_next() leads to the crash.
+local _
+for _ in (nil):foo() do end
+]])
+
+test:ok(res_f, 'chunk loaded sucsessfully')
+
+local res, err = pcall(res_f)
+
+test:ok(not res, 'loaded function not executed')
+test:like(err, 'attempt to index a nil value', 'correct error message')
+
+test:done(true)
--
2.41.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
2023-08-15 14:25 [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser Sergey Kaplun via Tarantool-patches
@ 2023-08-16 12:25 ` Maxim Kokryashkin via Tarantool-patches
2023-08-16 15:52 ` Sergey Kaplun via Tarantool-patches
2023-08-21 12:04 ` Sergey Bronnikov via Tarantool-patches
2023-08-31 15:19 ` Igor Munkin via Tarantool-patches
2 siblings, 1 reply; 7+ messages in thread
From: Maxim Kokryashkin via Tarantool-patches @ 2023-08-16 12:25 UTC (permalink / raw)
To: Sergey Kaplun; +Cc: tarantool-patches
Hi, Sergey!
Thanks for the patch!
LGTM, except for a few nits below.
On Tue, Aug 15, 2023 at 05:25:41PM +0300, Sergey Kaplun wrote:
> From: Mike Pall <mike>
>
> Reported by Sergey Kaplun.
>
> (cherry-picked from commit caf7cbc57c945f7b68871ad72abafb2b6e6fb7f5)
>
> Assume, we have the following Lua code:
> | local _
> | for _ in (nil):foo() do end
>
> The first part of the bytecode emitted for it is the following:
> | 0001 KNIL 0 1
> | 0002 MOV 2 1
> | 0003 TGETS 1 1 0 ; "foo"
> | 0004 CALL 1 4 2
>
> The `0001 KNIL` is a result of merging two `KPRI` instructions: one for
> the local variable, one for the slot with `nil` object. During parsing in
> `predict_next()` the second `MOV` bytecode is examined to set `pairs` or
> `next` local variable. But, as far as it moves `nil` value, that isn't
> an actual variable, so it has no the name this leads to the crash.
Typo: s/variable, so it/variable and/
Typo: s/the name this/name, that move/
>
> This patch adds the check to be sure that `RD` in the `MOV` bytecode is
Typo: s/the check/a check/
> an actual variable.
Please mention the lj_bc.h here, so it is obvious what `RD` is.
>
> Sergey Kaplun:
> * added the description and the test for the problem
>
> Part of tarantool/tarantool#8825
> ---
>
> Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1033-fix-parsing-predict-next
> PR: https://github.com/tarantool/tarantool/pull/8987
> Related issues:
> * https://github.com/LuaJIT/LuaJIT/issues/1033
> * https://github.com/tarantool/tarantool/issues/8825
>
> src/lj_parse.c | 1 +
> .../lj-1033-fix-parsing-predict-next.test.lua | 30 +++++++++++++++++++
> 2 files changed, 31 insertions(+)
> create mode 100644 test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
>
> diff --git a/src/lj_parse.c b/src/lj_parse.c
> index 3f6caaec..420b95cb 100644
> --- a/src/lj_parse.c
> +++ b/src/lj_parse.c
> @@ -2532,6 +2532,7 @@ static int predict_next(LexState *ls, FuncState *fs, BCPos pc)
> cTValue *o;
> switch (bc_op(ins)) {
> case BC_MOV:
> + if (bc_d(ins) >= fs->nactvar) return 0;
> name = gco2str(gcref(var_get(ls, fs, bc_d(ins)).name));
> break;
> case BC_UGET:
> diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> new file mode 100644
> index 00000000..624344eb
> --- /dev/null
> +++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> @@ -0,0 +1,30 @@
> +local tap = require('tap')
> +local test = tap.test('lj-1033-fix-parsing-predict-next')
> +
> +test:plan(3)
> +
> +local res_f = loadstring([[
> +-- This local variable is necessary, because it emits `KPRI`
> +-- bytecode, with which the next `KPRI` bytecode will be merged.
> +--
> +-- The resulting bytecode is the following:
> +--
> +-- 0001 KNIL 0 1
> +-- 0002 MOV 2 1
> +-- 0003 TGETS 1 1 0 ; "foo"
> +-- 0004 CALL 1 4 2
> +--
> +-- This MOV don't use any variable value from the stack, so the
Typo: s/don't/doesn't/
> +-- attempt to get the name in `predict_next() leads to the crash.
> +local _
> +for _ in (nil):foo() do end
> +]])
> +
> +test:ok(res_f, 'chunk loaded sucsessfully')
> +
> +local res, err = pcall(res_f)
> +
> +test:ok(not res, 'loaded function not executed')
> +test:like(err, 'attempt to index a nil value', 'correct error message')
> +
> +test:done(true)
> --
> 2.41.0
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
2023-08-16 12:25 ` Maxim Kokryashkin via Tarantool-patches
@ 2023-08-16 15:52 ` Sergey Kaplun via Tarantool-patches
0 siblings, 0 replies; 7+ messages in thread
From: Sergey Kaplun via Tarantool-patches @ 2023-08-16 15:52 UTC (permalink / raw)
To: Maxim Kokryashkin; +Cc: tarantool-patches
Hi, Maxim!
Thanks for the review!
Fixed your comments inline.
Branch is force-pushed.
On 16.08.23, Maxim Kokryashkin wrote:
> Hi, Sergey!
> Thanks for the patch!
> LGTM, except for a few nits below.
> On Tue, Aug 15, 2023 at 05:25:41PM +0300, Sergey Kaplun wrote:
> > From: Mike Pall <mike>
> >
> > Reported by Sergey Kaplun.
> >
<snipped>
> > The `0001 KNIL` is a result of merging two `KPRI` instructions: one for
> > the local variable, one for the slot with `nil` object. During parsing in
> > `predict_next()` the second `MOV` bytecode is examined to set `pairs` or
> > `next` local variable. But, as far as it moves `nil` value, that isn't
> > an actual variable, so it has no the name this leads to the crash.
> Typo: s/variable, so it/variable and/
> Typo: s/the name this/name, that move/
Fixed.
> >
> > This patch adds the check to be sure that `RD` in the `MOV` bytecode is
> Typo: s/the check/a check/
Fixed.
> > an actual variable.
> Please mention the lj_bc.h here, so it is obvious what `RD` is.
Fixed.
> >
> > Sergey Kaplun:
> > * added the description and the test for the problem
> >
> > Part of tarantool/tarantool#8825
> > ---
> >
> > Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1033-fix-parsing-predict-next
> > PR: https://github.com/tarantool/tarantool/pull/8987
> > Related issues:
> > * https://github.com/LuaJIT/LuaJIT/issues/1033
> > * https://github.com/tarantool/tarantool/issues/8825
> >
> > src/lj_parse.c | 1 +
> > .../lj-1033-fix-parsing-predict-next.test.lua | 30 +++++++++++++++++++
> > 2 files changed, 31 insertions(+)
> > create mode 100644 test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> >
> > diff --git a/src/lj_parse.c b/src/lj_parse.c
> > index 3f6caaec..420b95cb 100644
> > --- a/src/lj_parse.c
> > +++ b/src/lj_parse.c
<snipped>
> > +-- The resulting bytecode is the following:
> > +--
> > +-- 0001 KNIL 0 1
> > +-- 0002 MOV 2 1
> > +-- 0003 TGETS 1 1 0 ; "foo"
> > +-- 0004 CALL 1 4 2
> > +--
> > +-- This MOV don't use any variable value from the stack, so the
> Typo: s/don't/doesn't/
Fixed. See the iterative diff below:
===================================================================
diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
index 624344eb..63998d8c 100644
--- a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
+++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
@@ -14,7 +14,7 @@ local res_f = loadstring([[
-- 0003 TGETS 1 1 0 ; "foo"
-- 0004 CALL 1 4 2
--
--- This MOV don't use any variable value from the stack, so the
+-- This MOV doesn't use any variable value from the stack, so the
-- attempt to get the name in `predict_next() leads to the crash.
local _
for _ in (nil):foo() do end
===================================================================
<snipped>
> >
--
Best regards,
Sergey Kaplun
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
2023-08-15 14:25 [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser Sergey Kaplun via Tarantool-patches
2023-08-16 12:25 ` Maxim Kokryashkin via Tarantool-patches
@ 2023-08-21 12:04 ` Sergey Bronnikov via Tarantool-patches
2023-08-22 15:17 ` Sergey Kaplun via Tarantool-patches
2023-08-31 15:19 ` Igor Munkin via Tarantool-patches
2 siblings, 1 reply; 7+ messages in thread
From: Sergey Bronnikov via Tarantool-patches @ 2023-08-21 12:04 UTC (permalink / raw)
To: Sergey Kaplun, Maxim Kokryashkin; +Cc: tarantool-patches
Hi, Sergey
thanks for the patch! See comments inline.
On 8/15/23 17:25, Sergey Kaplun wrote:
> From: Mike Pall <mike>
>
> Reported by Sergey Kaplun.
>
> (cherry-picked from commit caf7cbc57c945f7b68871ad72abafb2b6e6fb7f5)
>
> Assume, we have the following Lua code:
> | local _
> | for _ in (nil):foo() do end
>
> The first part of the bytecode emitted for it is the following:
> | 0001 KNIL 0 1
> | 0002 MOV 2 1
> | 0003 TGETS 1 1 0 ; "foo"
> | 0004 CALL 1 4 2
>
> The `0001 KNIL` is a result of merging two `KPRI` instructions: one for
> the local variable, one for the slot with `nil` object. During parsing in
> `predict_next()` the second `MOV` bytecode is examined to set `pairs` or
> `next` local variable. But, as far as it moves `nil` value, that isn't
> an actual variable, so it has no the name this leads to the crash.
>
> This patch adds the check to be sure that `RD` in the `MOV` bytecode is
> an actual variable.
>
> Sergey Kaplun:
> * added the description and the test for the problem
>
> Part of tarantool/tarantool#8825
> ---
>
> Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1033-fix-parsing-predict-next
> PR: https://github.com/tarantool/tarantool/pull/8987
> Related issues:
> * https://github.com/LuaJIT/LuaJIT/issues/1033
> * https://github.com/tarantool/tarantool/issues/8825
>
> src/lj_parse.c | 1 +
> .../lj-1033-fix-parsing-predict-next.test.lua | 30 +++++++++++++++++++
> 2 files changed, 31 insertions(+)
> create mode 100644 test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
>
> diff --git a/src/lj_parse.c b/src/lj_parse.c
> index 3f6caaec..420b95cb 100644
> --- a/src/lj_parse.c
> +++ b/src/lj_parse.c
> @@ -2532,6 +2532,7 @@ static int predict_next(LexState *ls, FuncState *fs, BCPos pc)
> cTValue *o;
> switch (bc_op(ins)) {
> case BC_MOV:
> + if (bc_d(ins) >= fs->nactvar) return 0;
> name = gco2str(gcref(var_get(ls, fs, bc_d(ins)).name));
> break;
> case BC_UGET:
> diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> new file mode 100644
> index 00000000..624344eb
> --- /dev/null
> +++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> @@ -0,0 +1,30 @@
> +local tap = require('tap')
> +local test = tap.test('lj-1033-fix-parsing-predict-next')
> +
> +test:plan(3)
> +
> +local res_f = loadstring([[
> +-- This local variable is necessary, because it emits `KPRI`
> +-- bytecode, with which the next `KPRI` bytecode will be merged.
> +--
> +-- The resulting bytecode is the following:
> +--
> +-- 0001 KNIL 0 1
> +-- 0002 MOV 2 1
> +-- 0003 TGETS 1 1 0 ; "foo"
> +-- 0004 CALL 1 4 2
> +--
> +-- This MOV don't use any variable value from the stack, so the
> +-- attempt to get the name in `predict_next() leads to the crash.
What is a point to put a comment inside loadstring, not before it?
> +local _
> +for _ in (nil):foo() do end
> +]])
> +
> +test:ok(res_f, 'chunk loaded sucsessfully')
typo: sucsessfully -> successfully
> +
> +local res, err = pcall(res_f)
> +
> +test:ok(not res, 'loaded function not executed')
it is not clear for me what for do you need checking result code. I
would omit it.
Feel free to ignore.
> +test:like(err, 'attempt to index a nil value', 'correct error message')
> +
> +test:done(true)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
2023-08-21 12:04 ` Sergey Bronnikov via Tarantool-patches
@ 2023-08-22 15:17 ` Sergey Kaplun via Tarantool-patches
2023-08-24 7:50 ` Sergey Bronnikov via Tarantool-patches
0 siblings, 1 reply; 7+ messages in thread
From: Sergey Kaplun via Tarantool-patches @ 2023-08-22 15:17 UTC (permalink / raw)
To: Sergey Bronnikov; +Cc: tarantool-patches
Hi, Sergey!
Thanks for the review!
Fixed your comments inline.
On 21.08.23, Sergey Bronnikov wrote:
> Hi, Sergey
>
>
> thanks for the patch! See comments inline.
>
>
> On 8/15/23 17:25, Sergey Kaplun wrote:
> > From: Mike Pall <mike>
> >
> > Reported by Sergey Kaplun.
> >
> > (cherry-picked from commit caf7cbc57c945f7b68871ad72abafb2b6e6fb7f5)
> >
> > Assume, we have the following Lua code:
> > | local _
> > | for _ in (nil):foo() do end
> >
> > The first part of the bytecode emitted for it is the following:
> > | 0001 KNIL 0 1
> > | 0002 MOV 2 1
> > | 0003 TGETS 1 1 0 ; "foo"
> > | 0004 CALL 1 4 2
> >
> > The `0001 KNIL` is a result of merging two `KPRI` instructions: one for
> > the local variable, one for the slot with `nil` object. During parsing in
> > `predict_next()` the second `MOV` bytecode is examined to set `pairs` or
> > `next` local variable. But, as far as it moves `nil` value, that isn't
> > an actual variable, so it has no the name this leads to the crash.
> >
> > This patch adds the check to be sure that `RD` in the `MOV` bytecode is
> > an actual variable.
> >
> > Sergey Kaplun:
> > * added the description and the test for the problem
> >
> > Part of tarantool/tarantool#8825
> > ---
> >
> > Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1033-fix-parsing-predict-next
> > PR: https://github.com/tarantool/tarantool/pull/8987
> > Related issues:
> > * https://github.com/LuaJIT/LuaJIT/issues/1033
> > * https://github.com/tarantool/tarantool/issues/8825
> >
> > src/lj_parse.c | 1 +
> > .../lj-1033-fix-parsing-predict-next.test.lua | 30 +++++++++++++++++++
> > 2 files changed, 31 insertions(+)
> > create mode 100644 test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> >
> > diff --git a/src/lj_parse.c b/src/lj_parse.c
> > index 3f6caaec..420b95cb 100644
> > --- a/src/lj_parse.c
> > +++ b/src/lj_parse.c
> > @@ -2532,6 +2532,7 @@ static int predict_next(LexState *ls, FuncState *fs, BCPos pc)
> > cTValue *o;
> > switch (bc_op(ins)) {
> > case BC_MOV:
> > + if (bc_d(ins) >= fs->nactvar) return 0;
> > name = gco2str(gcref(var_get(ls, fs, bc_d(ins)).name));
> > break;
> > case BC_UGET:
> > diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> > new file mode 100644
> > index 00000000..624344eb
> > --- /dev/null
> > +++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> > @@ -0,0 +1,30 @@
> > +local tap = require('tap')
> > +local test = tap.test('lj-1033-fix-parsing-predict-next')
> > +
> > +test:plan(3)
> > +
> > +local res_f = loadstring([[
> > +-- This local variable is necessary, because it emits `KPRI`
> > +-- bytecode, with which the next `KPRI` bytecode will be merged.
> > +--
> > +-- The resulting bytecode is the following:
> > +--
> > +-- 0001 KNIL 0 1
> > +-- 0002 MOV 2 1
> > +-- 0003 TGETS 1 1 0 ; "foo"
> > +-- 0004 CALL 1 4 2
> > +--
> > +-- This MOV don't use any variable value from the stack, so the
> > +-- attempt to get the name in `predict_next() leads to the crash.
> What is a point to put a comment inside loadstring, not before it?
Moved the part about bytecode before. Still assume, that comment about
the variable is needed inside the code (i.e. this variable).
> > +local _
> > +for _ in (nil):foo() do end
> > +]])
> > +
> > +test:ok(res_f, 'chunk loaded sucsessfully')
> typo: sucsessfully -> successfully
Fixed, thanks!
> > +
> > +local res, err = pcall(res_f)
> > +
> > +test:ok(not res, 'loaded function not executed')
>
> it is not clear for me what for do you need checking result code. I
> would omit it.
>
> Feel free to ignore.
Added the following comment to avoid confusing (see the whole iterative
patch below):
===================================================================
diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
index 63998d8c..fed3ff6c 100644
--- a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
+++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
@@ -3,10 +3,6 @@ local test = tap.test('lj-1033-fix-parsing-predict-next')
test:plan(3)
-local res_f = loadstring([[
--- This local variable is necessary, because it emits `KPRI`
--- bytecode, with which the next `KPRI` bytecode will be merged.
---
-- The resulting bytecode is the following:
--
-- 0001 KNIL 0 1
@@ -16,14 +12,18 @@ local res_f = loadstring([[
--
-- This MOV doesn't use any variable value from the stack, so the
-- attempt to get the name in `predict_next() leads to the crash.
+local res_f = loadstring([[
+-- This local variable is necessary, because it emits `KPRI`
+-- bytecode, with which the next `KPRI` bytecode will be merged.
local _
for _ in (nil):foo() do end
]])
-test:ok(res_f, 'chunk loaded sucsessfully')
+test:ok(res_f, 'chunk loaded successfully')
local res, err = pcall(res_f)
+-- Check consistency with PUC Rio Lua 5.1 behaviour.
test:ok(not res, 'loaded function not executed')
test:like(err, 'attempt to index a nil value', 'correct error message')
===================================================================
Branch is force-pushed.
>
>
> > +test:like(err, 'attempt to index a nil value', 'correct error message')
> > +
> > +test:done(true)
--
Best regards,
Sergey Kaplun
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
2023-08-22 15:17 ` Sergey Kaplun via Tarantool-patches
@ 2023-08-24 7:50 ` Sergey Bronnikov via Tarantool-patches
0 siblings, 0 replies; 7+ messages in thread
From: Sergey Bronnikov via Tarantool-patches @ 2023-08-24 7:50 UTC (permalink / raw)
To: Sergey Kaplun; +Cc: tarantool-patches
Hi,
On 8/22/23 18:17, Sergey Kaplun wrote:
<snipped>
>>> +
>>> +local res, err = pcall(res_f)
>>> +
>>> +test:ok(not res, 'loaded function not executed')
>> it is not clear for me what for do you need checking result code. I
>> would omit it.
>>
>> Feel free to ignore.
> Added the following comment to avoid confusing (see the whole iterative
> patch below):
>
> ===================================================================
> diff --git a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> index 63998d8c..fed3ff6c 100644
> --- a/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> +++ b/test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
> @@ -3,10 +3,6 @@ local test = tap.test('lj-1033-fix-parsing-predict-next')
>
> test:plan(3)
>
> -local res_f = loadstring([[
> --- This local variable is necessary, because it emits `KPRI`
> --- bytecode, with which the next `KPRI` bytecode will be merged.
> ---
> -- The resulting bytecode is the following:
> --
> -- 0001 KNIL 0 1
> @@ -16,14 +12,18 @@ local res_f = loadstring([[
> --
> -- This MOV doesn't use any variable value from the stack, so the
> -- attempt to get the name in `predict_next() leads to the crash.
> +local res_f = loadstring([[
> +-- This local variable is necessary, because it emits `KPRI`
> +-- bytecode, with which the next `KPRI` bytecode will be merged.
> local _
> for _ in (nil):foo() do end
> ]])
>
> -test:ok(res_f, 'chunk loaded sucsessfully')
> +test:ok(res_f, 'chunk loaded successfully')
>
> local res, err = pcall(res_f)
>
> +-- Check consistency with PUC Rio Lua 5.1 behaviour.
> test:ok(not res, 'loaded function not executed')
> test:like(err, 'attempt to index a nil value', 'correct error message')
>
> ===================================================================
>
> Branch is force-pushed.
>
Thanks! LGTM now.
>>
>>> +test:like(err, 'attempt to index a nil value', 'correct error message')
>>> +
>>> +test:done(true)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser.
2023-08-15 14:25 [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser Sergey Kaplun via Tarantool-patches
2023-08-16 12:25 ` Maxim Kokryashkin via Tarantool-patches
2023-08-21 12:04 ` Sergey Bronnikov via Tarantool-patches
@ 2023-08-31 15:19 ` Igor Munkin via Tarantool-patches
2 siblings, 0 replies; 7+ messages in thread
From: Igor Munkin via Tarantool-patches @ 2023-08-31 15:19 UTC (permalink / raw)
To: Sergey Kaplun; +Cc: tarantool-patches
Sergey,
I've checked the patchset into all long-term branches in
tarantool/luajit and bumped a new version in master, release/2.11 and
release/2.10.
On 15.08.23, Sergey Kaplun via Tarantool-patches wrote:
> From: Mike Pall <mike>
>
> Reported by Sergey Kaplun.
>
> (cherry-picked from commit caf7cbc57c945f7b68871ad72abafb2b6e6fb7f5)
>
> Assume, we have the following Lua code:
> | local _
> | for _ in (nil):foo() do end
>
> The first part of the bytecode emitted for it is the following:
> | 0001 KNIL 0 1
> | 0002 MOV 2 1
> | 0003 TGETS 1 1 0 ; "foo"
> | 0004 CALL 1 4 2
>
> The `0001 KNIL` is a result of merging two `KPRI` instructions: one for
> the local variable, one for the slot with `nil` object. During parsing in
> `predict_next()` the second `MOV` bytecode is examined to set `pairs` or
> `next` local variable. But, as far as it moves `nil` value, that isn't
> an actual variable, so it has no the name this leads to the crash.
>
> This patch adds the check to be sure that `RD` in the `MOV` bytecode is
> an actual variable.
>
> Sergey Kaplun:
> * added the description and the test for the problem
>
> Part of tarantool/tarantool#8825
> ---
>
> Branch: https://github.com/tarantool/luajit/tree/skaplun/lj-1033-fix-parsing-predict-next
> PR: https://github.com/tarantool/tarantool/pull/8987
> Related issues:
> * https://github.com/LuaJIT/LuaJIT/issues/1033
> * https://github.com/tarantool/tarantool/issues/8825
>
> src/lj_parse.c | 1 +
> .../lj-1033-fix-parsing-predict-next.test.lua | 30 +++++++++++++++++++
> 2 files changed, 31 insertions(+)
> create mode 100644 test/tarantool-tests/lj-1033-fix-parsing-predict-next.test.lua
>
<snipped>
> --
> 2.41.0
>
--
Best regards,
IM
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-08-31 15:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-15 14:25 [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser Sergey Kaplun via Tarantool-patches
2023-08-16 12:25 ` Maxim Kokryashkin via Tarantool-patches
2023-08-16 15:52 ` Sergey Kaplun via Tarantool-patches
2023-08-21 12:04 ` Sergey Bronnikov via Tarantool-patches
2023-08-22 15:17 ` Sergey Kaplun via Tarantool-patches
2023-08-24 7:50 ` Sergey Bronnikov via Tarantool-patches
2023-08-31 15:19 ` Igor Munkin via Tarantool-patches
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox