Backport commit for fix recording of string.char() without arguments
#6371
Comments
Buristan
pushed a commit
to tarantool/luajit
that referenced
this issue
Aug 20, 2021
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. When JIT machinery records the aforementioned call it doesn't handle case without arguments. Each recording fast function expects 1 result by default. Hence, when return from this call is recorded the framelink slot is used as a result. It is loaded into the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TV on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference into the corresponding slot. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371
Buristan
pushed a commit
to tarantool/luajit
that referenced
this issue
Aug 20, 2021
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. When JIT machinery records the aforementioned call it doesn't handle this case. Each recording fast function expects 1 result by default. Hence, when return from this call is recorded the framelink slot is used as a result. It is loaded into the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference into the corresponding slot. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371
Buristan
pushed a commit
to tarantool/luajit
that referenced
this issue
Sep 1, 2021
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded the framelink slot (the top slot value) is considered as a result to yield. It is loaded into the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference into the corresponding slot. It reuses assumption of one result by default, hence there is no case for `i == 1` in the code. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371
Buristan
pushed a commit
to tarantool/luajit
that referenced
this issue
Jan 28, 2022
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded some garbarge value is considered as a result to yield. It is loaded into the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference into the corresponding slot. It reuses assumption of one result by default, hence there is no case for `i == 1` in the code. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371
Buristan
pushed a commit
to tarantool/luajit
that referenced
this issue
Jan 28, 2022
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded some garbarge value is considered as a result to yield. It is loaded into the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference into the corresponding slot. It reuses assumption of one result by default, hence there is no case for `i == 1` in the code. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371
igormunkin
pushed a commit
to tarantool/luajit
that referenced
this issue
Jan 28, 2022
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded, some garbage value is considered as a result to be yielded. It is loaded from the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference as a result value. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371 Part of tarantool/tarantool#6548 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Igor Munkin <imun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit f3e4906)
igormunkin
pushed a commit
to tarantool/luajit
that referenced
this issue
Jan 28, 2022
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded, some garbage value is considered as a result to be yielded. It is loaded from the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference as a result value. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371 Part of tarantool/tarantool#6548 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Igor Munkin <imun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit f3e4906)
|
The issue is resolved in scope of tarantool/luajit@f3e4906. The submodule was updated in tarantool in 2.10.0-beta2-68-g87461d5c7 (87461d5), 2.8.3-26-g5c7464403 (5c74644), 1.10.12-24-gb3982d4d0 (b3982d4). |
igormunkin
pushed a commit
to tarantool/luajit
that referenced
this issue
Jun 16, 2022
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded, some garbage value is considered as a result to be yielded. It is loaded from the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference as a result value. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371 Part of tarantool/tarantool#6548 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Igor Munkin <imun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
pushed a commit
to tarantool/luajit
that referenced
this issue
Jun 16, 2022
(cherry picked from commit dfa692b) `string.char()` call without arguments yields an empty string. JIT recording machinery doesn’t handle this case. Each recording of a fast function expects 1 result by default. Hence, when return from this call is recorded, some garbage value is considered as a result to be yielded. It is loaded from the corresponding slot as an IR with `IRT_NUM` type. It leads to assertion failure in `rec_check_slots()`, when a next bytecode is recorded, because type of TValue on the stack (`LJ_STR`) isn't the same as IR (and TRef) type. This patch handles the case without arguments by the loading of IR with empty string reference as a result value. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6371 Part of tarantool/tarantool#6548 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Igor Munkin <imun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reproducer:
The issue is fixed via commit LuaJIT/LuaJIT@dfa692b7 in the upstream.
The text was updated successfully, but these errors were encountered: