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 D141C596286; Mon, 21 Aug 2023 15:04:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D141C596286 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1692619490; bh=7hrXSVsmie12igjBGZz8d7KhU7Y1eVCmb3bWgYvOaII=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=xcNQQPxjcRf5L2U4O5xM0iCfV3QON4AtazPtNzKSyr53sOT4QBCSuGgwTcG4Ya7/Z aapigtG/uLYeoCFF5djXyqUn3xp/0CSn5Z+coOK6dZY4bhSBY9784QRkzYH+EzHNhJ 9GFlIXjYTL/rCK5jgwvYwlyU4EOT5GevtvC63OEk= Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [95.163.41.99]) (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 E2EDD59568B for ; Mon, 21 Aug 2023 15:04:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E2EDD59568B Received: by smtp61.i.mail.ru with esmtpa (envelope-from ) id 1qY3eJ-007szN-2j; Mon, 21 Aug 2023 15:04:48 +0300 Message-ID: <35c90999-f893-ed59-034d-4986e7b44b72@tarantool.org> Date: Mon, 21 Aug 2023 15:04:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: Sergey Kaplun , Maxim Kokryashkin Cc: tarantool-patches@dev.tarantool.org References: <20230815142541.29855-1-skaplun@tarantool.org> Content-Language: en-US In-Reply-To: <20230815142541.29855-1-skaplun@tarantool.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD93C8852532D76B9E3B62DC7F09619FD734679E2B1BE667DC6182A05F538085040E87B272B604561B5D1946D7D6A9F2861D08646F26ADF87E330270A7CA989A6F1 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7512BB5F8F28C04EEEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378BCFB34D7DDF138E8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8B4D919731A59993D1183A19D8349798B117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCECD08F8D939B2CE4A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD182CC0D3CB04F14752D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE9647ADFADE5905B14DC33E588678F033D8FC6C240DEA76429C9F4D5AE37F343AA9539A8B242431040A6AB1C7CE11FEE3632EDEA9CD5989A303F1AB874ED89028C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947C989FD0BDF65E50FB2E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89F0A35B161A8BF67C142539A7722CA490CB5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A5A756274E60ECE9FEE5AF63DEEDD58342DCD281A92BBA7DA0F87CCE6106E1FC07E67D4AC08A07B9B064E7220B7C550592CB5012B2E24CD356 X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF90C9A4E85626C6E15B430FC1802CF0D6DD2C2BD61BF59339D89A3DBF1E8947953CC8565881B595B6A7CA3A83B0F0804D8666853990FB837DEDB175870E3C2C59E48CAC7CA610320002C26D483E81D6BE0DBAE6F56676BC7117BB6831D7356A2DEC5B5AD62611EEC62B5AFB4261A09AF0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojHJI2DMjVra3HGyEHcXDyCw== X-Mailru-Sender: 11C2EC085EDE56FAC07928AF2646A769D7E9494EB3075509D1946D7D6A9F28617AD558DE3329E344EBA65886582A37BD66FEC6BF5C9C28D98A98C1125256619760D574B6FC815AB872D6B4FCE48DF648AE208404248635DF 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 Bronnikov via Tarantool-patches Reply-To: Sergey Bronnikov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 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? > +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)