From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id C091F5A357A; Tue, 22 Aug 2023 18:21:54 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C091F5A357A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1692717714; bh=U5mhCBcxO1i3P4sZshzvJ/Hf/hCbkt1q5yz8duMktoo=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=rv9QFxyQiaq/rGWAkZULGswhX58sJeMoIEstxk2Xqht4nVH6rP41pU8gtAVNrJmDB Ec94JkH0RZh/GN7CzYaqCxeZ4faDw2dpBzbS+P0897pXBAWUToBo8KF+Vp8YLstrE/ SMQpPTc/1bNSXLnENoDKac8WQBxeYYNLCLh9enU8= Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [95.163.41.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 858D2574A45 for ; Tue, 22 Aug 2023 18:21:53 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 858D2574A45 Received: by smtp56.i.mail.ru with esmtpa (envelope-from ) id 1qYTCa-00ACOG-0l; Tue, 22 Aug 2023 18:21:52 +0300 Date: Tue, 22 Aug 2023 18:17:08 +0300 To: Sergey Bronnikov Message-ID: References: <20230815142541.29855-1-skaplun@tarantool.org> <35c90999-f893-ed59-034d-4986e7b44b72@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35c90999-f893-ed59-034d-4986e7b44b72@tarantool.org> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD93C8852532D76B9E3B40810D8949158306E0746822E25C650182A05F53808504092E5680C9737F40D94E3F4B69467C9E8F6A00C5B545CDA45F7C08F5BF61A86FD X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7D9B0C78E17BAE9D7EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375E7A1B5661595F038638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8407B36886FADD3FB67C2172D55AB5164117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC0F49EF363AAD6E82A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE0AC5B80A05675ACDB78CF848AE20165DD8FC6C240DEA76429C9F4D5AE37F343AA9539A8B242431040A6AB1C7CE11FEE3093C2F12201C912A302FCEF25BFAB345C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947CA9FF340AA05FB58C2E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89F0A35B161A8BF67C15E1C53F199C2BB95B5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A5E136BA0D70A2B41ECBF7C3C16965486F8351C2138419A1DFF87CCE6106E1FC07E67D4AC08A07B9B00A6B3CD6EB70C818BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF91F26E0D17A058AA7E131DDAC3620271C524C1207D079C7F66593A91F937C2C24C7498080C0F87FCA7CA3A83B0F0804D9815557DBAAFE106C6E7B6A263515C16E48CAC7CA610320002C26D483E81D6BE5EF9655DD6DEA7D65774BB76CC95456EEC5B5AD62611EEC62B5AFB4261A09AF0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojjgfIa8ZOPyduWAlrzFnsog== X-Mailru-Sender: 11C2EC085EDE56FAC07928AF2646A7694C95308A5FED1ACD94E3F4B69467C9E8FE5F7FEA15315F16DEDBA653FF35249392D99EB8CC7091A70E183A470755BFD208F19895AA18418972D6B4FCE48DF648AE208404248635DF X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser. X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "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 > > > > 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