Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Backporting LuaJIT upstream commits part 5 #8825

Closed
35 tasks done
Tracked by #5483
Buristan opened this issue Jun 29, 2023 · 0 comments
Closed
35 tasks done
Tracked by #5483

Backporting LuaJIT upstream commits part 5 #8825

Buristan opened this issue Jun 29, 2023 · 0 comments
Assignees
@ligurio @mkokryashkin @Buristan
Labels
luajit

Comments

@Buristan
Copy link
Collaborator

Buristan commented Jun 29, 2023 •
edited by igormunkin

This ticket is an umbrella for all commits we planning to back-port in the next Q.
This list includes commits excluded from #8516 and may be updated later with some new.

general + x86/x64:

  • 93a65d3c Fix BC_UCLO insertion for returns.
  • 56c04acc FFI: Fix recording of union initialization.
  • 377a8488 Fix binary number literal parsing.
  • c50232eb Always exit after machine code page protection change fails.
  • c7db8255 Fix TDUP load forwarding after table rehash.
  • 9f452bbe Fix handling of instable types in TNEW/TDUP load forwarding.
  • 2d8300c1 Fix frame for on-trace out-of-memory error.
  • d5bbf9cd Fix frame for more types of on-trace error messages.
  • 0cc5fdfb Fix maxslots when recording BC_TSETM.
  • 0ef51b49 Handle table unsinking in the presence of IRFL_TAB_NOMM.
  • 94ada596 Fix maxslots when recording BC_VARG.
  • a01cba9d Fix maxslots when recording BC_VARG, part 2.
  • abb27c77 Fix maxslots when recording BC_VARG, part 3.
  • caf7cbc5 Fix predict_next() in parser.
  • 309fb42b Fix predict_next() in parser (again).

Refactoring and irrelevant (for Tarantool) patches required for backporintg "Fix pow inconsistencies" epic:

  • 7381b620 MIPS: Use precise search for exit jump patching.
  • c7c3c4da MIPS: Fix handling of spare long-range jump slots.
  • a057a07a MIPS64: Add soft-float support to JIT compiler backend.
  • fd37da0d PPC: Add soft-float support to interpreter.
  • 71b7bc88 PPC: Add soft-float support to JIT compiler backend.
  • c3c54ce1 Windows: Add UWP support, part 1.
  • 70f4b15e FFI: Eliminate hardcoded string hashes.
  • d4ee8034 Fix GCC 7 -Wimplicit-fallthrough warnings.
  • 9bd5a722 ARM: Fix GCC 7 -Wimplicit-fallthrough warnings.
  • 9b410621 DynASM: Fix warning.
  • 1c89933f Fix LJ_MAX_JSLOTS assertion in rec_check_slots().
  • 16e5605e Prevent integer overflow while parsing long strings.
  • 99cdfbf6 MIPS64: Fix register allocation in assembly of HREF.
  • 5c911998 DynASM/MIPS: Fix shadowed variable.
  • 94d0b530 MIPS: Add MIPS64 R6 port.

Fix pow inconsistencies:

  • b2307c8a Remove pow() splitting and cleanup backends.
  • 8ae5170c Improve assertions. (depends on pow() splitting b2307c8a)
  • 9512d5c1 Fix pow() optimization inconsistencies.
  • 96d6d503 Revert to trival pow() optimizations to prevent inaccuracies.

Other:

  • 72efc42e MIPS: Fix "bad FP FLOAD" assertion.
@igormunkin igormunkin mentioned this issue Jul 5, 2023
Open
12 tasks
Buristan pushed a commit to tarantool/luajit that referenced this issue Jul 10, 2023
@Buristan
Fix maxslots when recording BC_VARG.
323f1c0 
Analyzed by Sergey Kaplun.

(cherry-picked from commit 94ada59)

While recording BC_VARG `J->maxslot` isn't shrunk to the effective stack
top. This leads to dead value stored in the JIT slots and the following
assertion failure for these slots check in `rec_check_slots()`. Note,
that `rec_varg()` modifies `maxslot` only under the condition that
`maxslot` should be increased, but the dead values are left for the
opposite case.

This patch removes the condition inside `rec_varg()` only for the case
when varargs are not defined on trace (`framedepth` is 0), but the
similar issue still occurs for the case when vararg are defined on the
trace.

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
Buristan pushed a commit to tarantool/luajit that referenced this issue Jul 10, 2023
@Buristan
Fix maxslots when recording BC_VARG, part 2.
d89c7a1 
Analyzed by Sergey Kaplun.

(cherry-picked from commit a01cba9)

This patch is the follow-up for the previous one. It removes the
condition for `maxslot` changing in the case when varargs are defined
on the trace (i.e. `framedepth` > 0).

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
mkokryashkin pushed a commit to tarantool/luajit that referenced this issue Jul 10, 2023
@mkokryashkin
FFI: Fix recording of union initialization.
0656e3e 
Thanks to Alex Shpilkin.

(cherry-picked from commit 56c04ac)

As stated here[1], only the first field of a union can be
initialized with a flat initializer. However, before this
patch, on-trace initialization instructions were emitted
for other union members too, overwriting the previous
initialization values.

This patch fixes the mentioned behavior by preventing
initialization of members other than the first one.

[1]: https://luajit.org/ext_ffi_semantics.html#init

Maxim Kokryashkin:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
ligurio added a commit to ligurio/tarantool that referenced this issue Jul 10, 2023
@ligurio
luajit: bump new version
3ed8f55 
* Fix BC_UCLO insertion for returns.

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
NO_CHANGELOG=LuaJIT submodule bump
mkokryashkin pushed a commit to tarantool/luajit that referenced this issue Jul 12, 2023
@mkokryashkin
Mark CONV as non-weak, to prevent elimination of its side-effect.
dd1ba16 
An unused guarded CONV int.num cannot be omitted in general.

(cherry-picked from commit 881d02d)

In some cases, an unused `CONV` omission may lead to a guard
absence, resulting in invalid control flow branching and
undefined behavior. For a comprehensive example of
the described situation, please refer to the comment
in `test/tarantool-tests/mark-conv-non-weak.test.lua`.

Maxim Kokryashkin:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
mkokryashkin added a commit to mkokryashkin/tarantool that referenced this issue Jul 12, 2023
@mkokryashkin
LuaJIT: bump new version
b819849 
Mark CONV as non-weak, to prevent elimination of its side-effect.

Part of tarantool#8825

NO_DOC=LuaJIT bump
NO_TEST=LuaJIT bump
@mkokryashkin mkokryashkin mentioned this issue Jul 12, 2023
Closed
ligurio added a commit to ligurio/tarantool that referenced this issue Jul 13, 2023
@ligurio
luajit: bump new version
944c146 
* Fix BC_UCLO insertion for returns.

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
NO_CHANGELOG=LuaJIT submodule bump
ligurio added a commit to ligurio/tarantool that referenced this issue Jul 13, 2023
@ligurio
luajit: bump new version
5156922 
* Fix BC_UCLO insertion for returns.

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
NO_CHANGELOG=LuaJIT submodule bump
mkokryashkin pushed a commit to tarantool/luajit that referenced this issue Jul 14, 2023
@mkokryashkin
FFI: Fix recording of union initialization.
52849c5 
Thanks to Alex Shpilkin.

(cherry-picked from commit 56c04ac)

As stated here[1], only the first field of a union can be
initialized with a flat initializer. However, before this
patch, on-trace initialization instructions were emitted
for other union members too, overwriting the previous
initialization values.

This patch fixes the mentioned behavior by preventing
initialization of members other than the first one.

[1]: https://luajit.org/ext_ffi_semantics.html#init

Maxim Kokryashkin:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
Buristan pushed a commit to tarantool/luajit that referenced this issue Jul 15, 2023
@Buristan
Fix maxslots when recording BC_VARG.
4065e62 
Analyzed by Sergey Kaplun.

(cherry-picked from commit 94ada59)

While recording BC_VARG `J->maxslot` isn't shrunk to the effective stack
top. This leads to dead values stored in the JIT slots and the following
assertion failure for these slots check in `rec_check_slots()`. Note,
that `rec_varg()` modifies `maxslot` only under the condition that
`maxslot` should be increased, but the dead values are left for the
opposite case.

This patch removes the condition inside `rec_varg()` only for the case
when varargs are not defined on trace (`framedepth` is 0), but the
similar issue still occurs for the case when varargs are defined on the
trace.

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
Buristan pushed a commit to tarantool/luajit that referenced this issue Jul 15, 2023
@Buristan
Fix maxslots when recording BC_VARG, part 2.
fb98a70 
Analyzed by Sergey Kaplun.

(cherry-picked from commit a01cba9)

This patch is a follow-up to the previous one. It removes the
condition for `maxslot` changing in the case when varargs are defined
on the trace (i.e. `framedepth` > 0).

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@Buristan @igormunkin
Fix BC_UCLO insertion for returns.
a951a90 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
Co-authored-by: Sergey Kaplun <skaplun@tarantool.org>
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@igormunkin
Fix BC_UCLO insertion for returns.
7051b5f 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
Co-developed-by: Sergey Kaplun <skaplun@tarantool.org>
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@igormunkin
Fix BC_UCLO insertion for returns.
8ee50b9 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@igormunkin
Fix BC_UCLO insertion for returns.
a955299 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Helped-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@igormunkin
Fix BC_UCLO insertion for returns.
47f5383 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Helped-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
Reviewed-by: Maxim Kokryashkin <m.kokryashkin@tarantool.org>
Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@igormunkin
Fix BC_UCLO insertion for returns.
3c7aff4 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Helped-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
Reviewed-by: Maxim Kokryashkin <m.kokryashkin@tarantool.org>
Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
(cherry picked from commit 47f5383)
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@igormunkin
Fix BC_UCLO insertion for returns.
3a63f05 
Contributed by XmiliaH.

(cherry-picked from commit 93a65d3)

Patch fixes a problem when LuaJIT generates a wrong bytecode with a
missed BC_UCLO instruction. When some of BC_RET bytecode instructions are
not fixup-ed, due to an early return, if UCLO is obtained before, those
leads to VM inconsistency after return from the function.

Patch makes the following changes in bytecode (thats it, emits extra
BC_UCLO instruction that closes upvalues):

@@ -11,11 +11,12 @@
 0006 => LOOP     1 => 0012
 0007    ISF          0
 0008    JMP      1 => 0010
-0009    RET1     0   2
+0009    UCLO     0 => 0014
 0010 => FNEW     0   0      ; uclo.lua:56
 0011    JMP      1 => 0006
 0012 => UCLO     0 => 0001
 0013 => RET0     0   1
+0014 => RET1     0   2

NOTE: After emitting the bytecode instruction BC_FNEW fixup is not
required, because FuncState will set a flag PROTO_CHILD that will
trigger emitting a pair of instructions BC_UCLO and BC_RET (see
<src/lj_parse.c:2355>) and BC_RET will close all upvalues from a base
equal to 0.

JIT compilation of missing_uclo() function without a patch with fix is failed:
src/lj_record.c:135: rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) - (TRef)(IRT_NUM) <= (TRef)(IRT_INT-IRT_NUM)))' failed.
(Thanks to Sergey Kaplun for discovering this!)
Thus second testcase in a test covers a case with compilation as well.

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825

Helped-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
Reviewed-by: Maxim Kokryashkin <m.kokryashkin@tarantool.org>
Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
(cherry picked from commit 47f5383)
mkokryashkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@mkokryashkin
FFI: Fix recording of union initialization.
348b733 
Thanks to Alex Shpilkin.

(cherry-picked from commit 56c04ac)

As stated here[1], only the first field of a union can be
initialized with a flat initializer. However, before this
patch, on-trace initialization instructions were emitted
for other union members too, overwriting the previous
initialization values.

This patch fixes the mentioned behavior by preventing
initialization of members other than the first one.

[1]: https://luajit.org/ext_ffi_semantics.html#init

Maxim Kokryashkin:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
mkokryashkin pushed a commit to tarantool/luajit that referenced this issue Jul 17, 2023
@mkokryashkin
Mark CONV as non-weak, to prevent elimination of its side-effect.
68cc359 
An unused guarded CONV int.num cannot be omitted in general.

(cherry-picked from commit 881d02d)

In some cases, an unused `CONV int.num` omission in `DUALNUM` mode
may lead to a guard absence, resulting in invalid control flow
branching and undefined behavior. For a comprehensive example of
the described situation, please refer to the comment
in `test/tarantool-tests/mark-conv-non-weak.test.lua`.

Maxim Kokryashkin:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
mkokryashkin added a commit to mkokryashkin/tarantool that referenced this issue Jul 17, 2023
@mkokryashkin
LuaJIT: bump new version
7442219 
Mark CONV as non-weak, to prevent elimination of its side-effect.

Part of tarantool#8825

NO_DOC=LuaJIT bump
NO_TEST=LuaJIT bump
Buristan pushed a commit to tarantool/luajit that referenced this issue Jul 18, 2023
@Buristan
Fix maxslots when recording BC_VARG.
8d58e1f 
Analyzed by Sergey Kaplun.

(cherry-picked from commit 94ada59)

While recording BC_VARG `J->maxslot` isn't shrunk to the effective stack
top. This leads to dead values stored in the JIT slots and the following
assertion failure for these slots check in `rec_check_slots()`. Note,
that `rec_varg()` modifies `maxslot` only under the condition that
`maxslot` should be increased, but the dead values are left for the
opposite case.

This patch removes the condition inside `rec_varg()` only for the case
when varargs are not defined on trace (`framedepth` is 0), but the
similar issue still occurs for the case when varargs are defined on the
trace.

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
Buristan pushed a commit to tarantool/luajit that referenced this issue Jul 18, 2023
@Buristan
Fix maxslots when recording BC_VARG, part 2.
ca51839 
Analyzed by Sergey Kaplun.

(cherry-picked from commit a01cba9)

This patch is a follow-up to the previous one. It removes the
condition for `maxslot` changing in the case when varargs are defined
on the trace (i.e. `framedepth` > 0).

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
igormunkin pushed a commit to tarantool/luajit that referenced this issue Jul 18, 2023
@igormunkin
Fix maxslots when recording BC_VARG.
30e49eb 
Analyzed by Sergey Kaplun.

(cherry-picked from commit 94ada59)

While recording BC_VARG `J->maxslot` isn't shrunk to the effective stack
top. This leads to dead values stored in the JIT slots and the following
assertion failure for these slots check in `rec_check_slots()`. Note,
that `rec_varg()` modifies `maxslot` only under the condition that
`maxslot` should be increased, but the dead values are left for the
opposite case.

This patch removes the condition inside `rec_varg()` only for the case
when varargs are not defined on trace (`framedepth` is 0), but the
similar issue still occurs for the case when varargs are defined on the
trace.

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
igormunkin added a commit that referenced this issue Sep 27, 2023
@igormunkin
luajit: bump new version
f3490f3 
* test: fix fix-mips64-spare-side-exit-patching
* test: fix `fillmcode()` generator helper
* MIPS: Fix "bad FP FLOAD" assertion.
* Handle table unsinking in the presence of IRFL_TAB_NOMM.
* Fix handling of instable types in TNEW/TDUP load forwarding.
* Fix predict_next() in parser (again).
* Always exit after machine code page protection change fails.

Part of #8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
igormunkin added a commit that referenced this issue Sep 27, 2023
@igormunkin
luajit: bump new version
2757a84 
* test: fix fix-mips64-spare-side-exit-patching
* test: fix `fillmcode()` generator helper
* MIPS: Fix "bad FP FLOAD" assertion.
* Handle table unsinking in the presence of IRFL_TAB_NOMM.
* Fix handling of instable types in TNEW/TDUP load forwarding.
* Fix predict_next() in parser (again).
* Always exit after machine code page protection change fails.

Part of #8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
mkokryashkin pushed a commit to tarantool/luajit that referenced this issue Sep 29, 2023
@mkokryashkin
Fix snapshot PC when linking to BC_JLOOP that was a BC_RET*.
b3e5c87 
Reported by Arseny Vakhrushev.
Fix contributed by Peter Cawley.

As specified in the comment in `lj_record_stop`, all loops must
set `J->pc` to the next instruction. However, the chunk of logic
in `lj_trace_exit` expects it to be set to `BC_JLOOP` itself if
it used to be a `BC_RET`. This wrong pc results in the execution
of random data that goes after `BC_JLOOP` in the case of
restoration from the snapshot.

This patch fixes that behavior by adapting the loop recording
logic to this specific case.

Maxim Kokryashkin:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
mkokryashkin added a commit to mkokryashkin/tarantool that referenced this issue Sep 29, 2023
@mkokryashkin
luajit: bump new version
0667639 
Fix snapshot PC when linking to BC_JLOOP that was a BC_RET*.

Part of tarantool#8825

NO_DOC=LuaJIT bump
NO_TEST=LuaJIT bump
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 3, 2023
@ligurio
LJ_GC64: Fix lua_concat().
a9ae343 
Reported by Mathias Westerdahl.

(cherry picked from commit 633f265)

Lua 5.1 Reference Manual [1] defines a function `lua_concat`, that:

> void lua_concat (lua_State *L, int n);
>
> Concatenates the n values at the top of the stack, pops them, and leaves
> the result at the top.

Without the patch `lua_concat()` behaved incorrectly with userdata with
defined `__concat` metamethod. The problem is GC64-specific.

Assuming we have three literals and a userdata with defined "__concat"
metamethod on top of the Lua stack:

1 [string]
2 [string]
3 [string]
4 [string]
5 [userdata] <--- top

On attempt to concatenate *two* items on top of the Lua stack,
`lua_concat()` concatenates *four* items and leaves result on the top:

1 [string]
2 [string][string][string][userdata] <--- top

The problem is in incorrect calculation of `n` counter in the loop in
implementation of function `lua_concat`. Without the fix `n` is equal to
3 at the end of the first iteration and therefore it goes to the next
iteration of concatenation. In the fixed implementation of
`lua_concat()` `n` is equal to 1 at the end of the first loop iteration,
decremented in a loop postcondition and breaks the loop.

The patch fixes incorrect behaviour.

1. https://www.lua.org/manual/5.1/manual.html

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
ligurio added a commit to ligurio/tarantool that referenced this issue Oct 3, 2023
@ligurio
luajit: bump new version
b86ff6d 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio added a commit to ligurio/tarantool that referenced this issue Oct 3, 2023
@ligurio
luajit: bump new version
b6bac41 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 6, 2023
@ligurio
LJ_GC64: Fix lua_concat().
a84e3f6 
Reported by Mathias Westerdahl.

(cherry picked from commit 633f265)

Lua 5.1 Reference Manual [1] defines a function `lua_concat`, that:

> void lua_concat (lua_State *L, int n);
>
> Concatenates the n values at the top of the stack, pops them, and leaves
> the result at the top.

Without the patch `lua_concat()` behaved incorrectly with userdata with
defined `__concat` metamethod. The problem is GC64-specific.

Assuming we have three literals and a userdata with defined "__concat"
metamethod on top of the Lua stack:

1 [string]
2 [string]
3 [string]
4 [string]
5 [userdata] <--- top

On attempt to concatenate *two* items on top of the Lua stack,
`lua_concat()` concatenates *four* items and leaves result on the top:

1 [string]
2 [string][string][string][userdata] <--- top

The problem is in incorrect calculation of `n` counter in the loop in
implementation of function `lua_concat`. Without the fix `n` is equal to
3 at the end of the first iteration and therefore it goes to the next
iteration of concatenation. In the fixed implementation of
`lua_concat()` `n` is equal to 1 at the end of the first loop iteration,
decremented in a loop postcondition and breaks the loop.

The patch fixes incorrect behaviour.

1. https://www.lua.org/manual/5.1/manual.html

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
ligurio added a commit to ligurio/tarantool that referenced this issue Oct 6, 2023
@ligurio
luajit: bump new version
8d5f01c 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 6, 2023
@ligurio
LJ_GC64: Fix lua_concat().
46e7ad1 
Reported by Mathias Westerdahl.

(cherry picked from commit 633f265)

Lua 5.1 Reference Manual [1] defines a function `lua_concat`, that:

> void lua_concat (lua_State *L, int n);
>
> Concatenates the n values at the top of the stack, pops them, and leaves
> the result at the top.

Without the patch `lua_concat()` behaved incorrectly with userdata with
defined `__concat` metamethod. The problem is GC64-specific.

Assuming we have three literals and a userdata with defined "__concat"
metamethod on top of the Lua stack:

1 [string]
2 [string]
3 [string]
4 [string]
5 [userdata] <--- top

On attempt to concatenate *two* items on top of the Lua stack,
`lua_concat()` concatenates *four* items and leaves result on the top:

1 [string]
2 [string][string][string][userdata] <--- top

The problem is in incorrect calculation of `n` counter in the loop in
implementation of function `lua_concat`. Without the fix `n` is equal to
3 at the end of the first iteration and therefore it goes to the next
iteration of concatenation. In the fixed implementation of
`lua_concat()` `n` is equal to 1 at the end of the first loop iteration,
decremented in a loop postcondition and breaks the loop.

The patch fixes incorrect behaviour.

1. https://www.lua.org/manual/5.1/manual.html

Sergey Bronnikov:
* added the description and the test for the problem

Part of tarantool/tarantool#8825
ligurio added a commit to ligurio/tarantool that referenced this issue Oct 6, 2023
@ligurio
luajit: bump new version
f10e998 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 6, 2023
@ligurio
LJ_GC64: Always snapshot functions for non-base frames.
8cc0e36 
Reported by Arseny Vakhrushev.
Analysis and fix contributed by Peter Cawley.

(cherry picked from commit ff1e72a)

The problem is GC64-specific and could be reproduced with enabled
compiler options LUA_USE_ASSERT and LUA_USE_APICHECK.

Sergey Kaplun:
  * minimized reproducer made by fuzzing test

Sergey Bronnikov:
  * added the description and the tests for the problem: first one based
    on original reproducer and second one based on reproducer made by
    fuzzing test.

Part of tarantool/tarantool#8825

------------

cmake -S . -B build -DLUAJIT_ENABLE_GC64=ON -DCMAKE_BUILD_TYPE=Debug -DLUA_USE_APICHECK=ON -DLUA_USE_ASSERT=ON
ligurio added a commit to ligurio/tarantool that referenced this issue Oct 10, 2023
@ligurio
luajit: bump new version
97e1f52 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio added a commit to ligurio/tarantool that referenced this issue Oct 10, 2023
@ligurio
luajit: bump new version
414dfc9 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 12, 2023
@ligurio
LJ_GC64: Always snapshot functions for non-base frames.
6199420 
Reported by Arseny Vakhrushev.
Analysis and fix contributed by Peter Cawley.

(cherry picked from commit ff1e72a)

The problem is GC64-specific and could be reproduced with enabled
compiler options LUA_USE_ASSERT and LUA_USE_APICHECK.

Sergey Kaplun:
  * minimized reproducer made by fuzzing test

Sergey Bronnikov:
  * added the description (see a comment in the test)
  * added tests for the problem: first one based on the original
    reproducer and second one based on a reproducer made by fuzzing test.

Part of tarantool/tarantool#8825
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 12, 2023
@ligurio
LJ_GC64: Always snapshot functions for non-base frames.
d668177 
Reported by Arseny Vakhrushev.
Analysis and fix contributed by Peter Cawley.

(cherry picked from commit ff1e72a)

The problem is GC64-specific and could be reproduced with enabled
compiler options LUA_USE_ASSERT and LUA_USE_APICHECK.

Sergey Kaplun:
  * minimized reproducer made by fuzzing test

Sergey Bronnikov:
  * added the description (see a comment in the test)
  * added tests for the problem: first one based on the original
    reproducer and second one based on a reproducer made by fuzzing test.

Part of tarantool/tarantool#8825
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 12, 2023
@ligurio
LJ_GC64: Always snapshot functions for non-base frames.
8d9d59b 
Reported by Arseny Vakhrushev.
Analysis and fix contributed by Peter Cawley.

(cherry picked from commit ff1e72a)

The problem is GC64-specific and could be reproduced with enabled
compiler options LUA_USE_ASSERT and LUA_USE_APICHECK.

Sergey Kaplun:
  * minimized reproducer made by fuzzing test

Sergey Bronnikov:
  * added the description (see a comment in the test)
  * added tests for the problem: first one based on the original
    reproducer and second one based on a reproducer made by fuzzing test.

Part of tarantool/tarantool#8825
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 20, 2023
@ligurio
Fix embedded bytecode loader.
54b2111 
(cherry-picked from commit 8203399)

The original problem is specific to x32 and is as follows: when a chunk
with a bytecode library is loaded into memory, and the address is higher
than 0x80000100, the `LexState->pe`, that contains an address of the end
of the bytecode chunk in the memory, will wrap around and become smaller
than the address in `LexState->p`, that contains an address of the
beginning of bytecode chunk in the memory. In `bcread_fill()` called by
`bcread_want()`, `memcpy()` is called with a very large size and causes
the bus error on x86 and the segmentation fault on ARM Android.

The problem cannot be reproduced on platforms supported by Tarantool
(ARM64, x86_64), so test doesn't reproduce a problem without a patch and
tests the patch partially.

Sergey Bronnikov:
* added the description and the test

Part of tarantool/tarantool#8825
ligurio pushed a commit to tarantool/luajit that referenced this issue Oct 20, 2023
@ligurio
Followup fix for embedded bytecode loader.
66d5e44 
(cherry-picked from commit e49863e)

The patch follows up a previous patch and limits the total size of a
chunk load by `lua_load` with size `LJ_MAX_BUF - 1`.

The proposed test `lj-549-lua-load.test` checks corner cases in
`lua_load` function and covers this and the previous patch partially.

Sergey Bronnikov:
* added the description and the test

Part of tarantool/tarantool#8825
ligurio added a commit to ligurio/tarantool that referenced this issue Nov 15, 2023
@ligurio
luajit: bump new version
2f0955c 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio added a commit to ligurio/tarantool that referenced this issue Nov 15, 2023
@ligurio
luajit: bump new version
b30d9be 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
mkokryashkin added a commit to mkokryashkin/tarantool that referenced this issue Nov 15, 2023
@mkokryashkin
test: remove finalizers table overflow test
4668344 
This test is no longer needed in the Tarantool test suite
since it was added to LuaJIT's test suite along with the fix
for the issue mentioned in tarantool#3060 in scope of tarantool#8825 in commit
7b98314e0dacc7313c061aceeb0a32afd4e8cbce ('Fix frame for more
types of on-trace error messages.').

Closes tarantool#3060
Related to tarantool#8825

NO_DOC=Cleanup
NO_TEST=Already included in LuaJIT bump
NO_CHANGELOG=Already included in LuaJIT bump
@mkokryashkin mkokryashkin mentioned this issue Nov 15, 2023
Merged
ligurio added a commit to ligurio/tarantool that referenced this issue Nov 15, 2023
@ligurio
luajit: bump new version
72dc6d7 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
mkokryashkin added a commit to mkokryashkin/tarantool that referenced this issue Nov 16, 2023
@mkokryashkin
test: remove finalizers table overflow test
7db209d 
This test is no longer needed in the Tarantool test suite
since it was added to LuaJIT's test suite along with the fix
for the issue mentioned in tarantool#3060 in scope of tarantool#8825 in commit
tarantool/luajit@7b98314.

Closes tarantool#3060
Related to tarantool#8825

NO_DOC=Cleanup
NO_TEST=Already included in LuaJIT bump
NO_CHANGELOG=Already included in LuaJIT bump
igormunkin pushed a commit that referenced this issue Nov 16, 2023
@mkokryashkin @igormunkin
test: remove finalizers table overflow test
e99f6cb 
This test is no longer needed in the Tarantool test suite
since it was added to LuaJIT's test suite along with the fix
for the issue mentioned in #3060 in scope of #8825 in commit
tarantool/luajit@7b98314.

Closes #3060
Related to #8825

NO_DOC=Cleanup
NO_TEST=Already included in LuaJIT bump
NO_CHANGELOG=Already included in LuaJIT bump
ligurio added a commit to ligurio/tarantool that referenced this issue Nov 18, 2023
@ligurio
luajit: bump new version
87b5536 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio added a commit to ligurio/tarantool that referenced this issue Nov 20, 2023
@ligurio
luajit: bump new version
5baf075 
* LJ_GC64: Fix lua_concat().

Part of tarantool#8825

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
ligurio pushed a commit to tarantool/luajit that referenced this issue Dec 15, 2023
@ligurio
LJ_GC64: Fix HREFK optimization.
ed6011c 
Contributed by XmiliaH.

(cherry picked from commit 91bc6b8)

Sergey Bronnikov:
  * added the description and the test for the problem

Part of tarantool/tarantool#8825
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ligurio ligurio

@mkokryashkin mkokryashkin

@Buristan Buristan

Labels
luajit
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ligurio @igormunkin @mkokryashkin @Buristan