From: Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Maxim Kokryashkin <m.kokryashkin@tarantool.org>, Sergey Bronnikov <estetus@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit] Prevent loop in snap_usedef(). Date: Thu, 16 Jan 2025 19:18:25 +0300 [thread overview] Message-ID: <8eec6092-5844-4264-9912-bcc1a4c6f74a@tarantool.org> (raw) In-Reply-To: <3nc2evmifho2awf6yzddx3uh7cskiwfafvtje46jnzhi47nwvv@x43uhh7wkbtx> [-- Attachment #1: Type: text/plain, Size: 5147 bytes --] Hi, Maxim, thanks for review! Please see my comments below. Fixes applied and force-pushed. On 26.03.2024 19:04, Maxim Kokryashkin wrote: > Hi, Sergey! > Thanks for the patch! > Please consider my comments below. > On Tue, Mar 26, 2024 at 06:29:11PM +0300, Sergey Bronnikov wrote: >> From: Sergey Bronnikov<sergeyb@tarantool.org> >> >> Reported by XmiliaH. >> >> (cherry picked from commit 0e66fc96377853d898390f1a02723c54ec3a42f7) >> >> It is possible to get an infinite loop in a function `snap_usedef` >> when a `UCLO` makes a tight loop. > The description should include explanation for the cause of the issue > and should explain how it was resolved. Added more details about patch to commit message: Updated description: It is possible to get an infinite loop in a function `snap_usedef` when a `UCLO` makes a tight loop. This infinite loop could happen when `snap_usedef()` is called on trace exit processes UCLO bytecode instruction and this instruction attempts a jump with negative value. The patch fixes the problem by checking a number of slots in a jump argument and replace this value my `maxslot` if a value is negative. >> Sergey Bronnikov: >> * added the description and the test for the problem >> >> Part of tarantool/tarantool#9595 >> --- >> Branch:https://github.com/tarantool/luajit/tree/ligurio/lj-736-prevent-loop-in-snap_usedef >> Issues: >> -https://github.com/LuaJIT/LuaJIT/issues/736 >> -https://github.com/tarantool/tarantool/issues/9595 >> >> src/lj_snap.c | 7 ++- >> .../lj-736-BC_UCLO-triggers-infinite-loop.lua | 59 +++++++++++++++++++ >> 2 files changed, 65 insertions(+), 1 deletion(-) >> create mode 100644 test/tarantool-tests/lj-736-BC_UCLO-triggers-infinite-loop.lua >> >> diff --git a/src/lj_snap.c b/src/lj_snap.c >> index 5a00b5cd..0710e1f0 100644 >> --- a/src/lj_snap.c >> +++ b/src/lj_snap.c >> @@ -252,7 +252,12 @@ static BCReg snap_usedef(jit_State *J, uint8_t *udf, >> BCReg minslot = bc_a(ins); >> if (op >= BC_FORI && op <= BC_JFORL) minslot += FORL_EXT; >> else if (op >= BC_ITERL && op <= BC_JITERL) minslot += bc_b(pc[-2])-1; >> - else if (op == BC_UCLO) { pc += bc_j(ins); break; } >> + else if (op == BC_UCLO) { >> + ptrdiff_t delta = bc_j(ins); >> + if (delta < 0) return maxslot; /* Prevent loop. */ >> + pc += delta; >> + break; >> + } >> for (s = minslot; s < maxslot; s++) DEF_SLOT(s); >> return minslot < maxslot ? minslot : maxslot; >> } >> diff --git a/test/tarantool-tests/lj-736-BC_UCLO-triggers-infinite-loop.lua b/test/tarantool-tests/lj-736-BC_UCLO-triggers-infinite-loop.lua >> new file mode 100644 >> index 00000000..28a2b61b >> --- /dev/null >> +++ b/test/tarantool-tests/lj-736-BC_UCLO-triggers-infinite-loop.lua >> @@ -0,0 +1,59 @@ >> +local tap = require('tap') >> +local test = tap.test('lj-736-BC_UCLO-triggers-infinite-loop'):skipcond({ >> + ['Test requires JIT enabled'] = not jit.status(), >> +}) >> + >> +test:plan(1) >> + >> +-- Test reproduces an issue when BC_UCLO triggers an infinite loop. >> +-- See details inhttps://github.com/LuaJIT/LuaJIT/issues/736. >> +-- >> +-- Listing below demonstrates a problem - >> +-- the bytecode UCLO on the line 13 makes a loop at 0013-0014: >> +-- >> +-- - BYTECODE -- bc_uclo.lua:0-20 >> +-- 0001 KPRI 0 0 >> +-- 0002 FNEW 1 0 ; bc_uclo.lua:5 >> +-- 0003 KSHORT 2 1 >> +-- 0004 KSHORT 3 4 >> +-- 0005 KSHORT 4 1 >> +-- 0006 FORI 2 => 0011 >> +-- 0007 => ISNEN 5 0 ; 2 >> +-- 0008 JMP 6 => 0010 >> +-- 0009 UCLO 0 => 0012 >> +-- 0010 => FORL 2 => 0007 >> +-- 0011 => UCLO 0 => 0012 >> +-- 0012 => KPRI 0 0 >> +-- 0013 UCLO 0 => 0012 >> +-- 0014 FNEW 1 1 ; bc_uclo.lua:18 >> +-- 0015 UCLO 0 => 0016 >> +-- 0016 => RET0 0 1 >> + >> +jit.opt.start('hotloop=1') >> + >> +do >> + local uv = 0 >> + local w = function() return uv end -- luacheck: no unused >> + for i = 1, 2 do > Add a comment that we have two iterations only because we only > need to record the trace. Added. >> + -- Infinite loop is here. >> + if i == 2 then >> + if i == 2 then >> + goto pass >> + end >> + goto unreachable >> + end >> + end >> +end >> + >> +::unreachable:: >> +-- Lua chunk below is required for reproducing a bug. >> +do >> + local uv = 0 -- luacheck: no unused >> + goto unreachable >> + local w = function() return uv end -- luacheck: ignore >> +end >> + >> +::pass:: > Please add a comment explaining why do we need a goto statement > and an unreachable code segment. Added more comments to the test. >> + >> +test:ok(true, 'BC_UCLO does not trigger an infinite loop') >> +os.exit(test:check() and 0 or 1) > The test executes without any failures for the x86 non-GC64 > build before the patch. The exact command: > $ cmake .. -DCMAKE_BUILD_TYPE=Debug -DLUA_USE_ASSERT=ON -DLUA_USE_APICHECK=ON && make -j && make test Fixed that. Now without patch test hangs and passed with applied patch. >> -- >> 2.34.1 >> [-- Attachment #2: Type: text/html, Size: 7360 bytes --]
prev parent reply other threads:[~2025-01-16 16:18 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-26 15:29 Sergey Bronnikov via Tarantool-patches 2024-03-26 16:04 ` Maxim Kokryashkin via Tarantool-patches 2025-01-16 16:18 ` Sergey Bronnikov via Tarantool-patches [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8eec6092-5844-4264-9912-bcc1a4c6f74a@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=estetus@gmail.com \ --cc=m.kokryashkin@tarantool.org \ --cc=sergeyb@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit] Prevent loop in snap_usedef().' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox