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 0E3856F87B; Fri, 28 Jan 2022 11:28:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0E3856F87B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1643358499; bh=k4Mgv2YlLr6F8BX6PRI6Rsm/KFhdW/mh1JEXaA1hp28=; 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=uPubP7dp6e139Z+eVmbdj+Bu0hwf/mK0i9TlOK8xoBCsmdp5K+F/qoUojKRZPXgaF L0Z5v792K4oXskSEQVc56yeXrtO8czn+Tgd/VxIYJKCQeBMTx6B1Uo24v0hAOvPQNo hfEZuAcjsNBOnF28FHOt0+PhTNltsyCd6YLFKjYw= Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C51F36F87B for ; Fri, 28 Jan 2022 11:28:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C51F36F87B Received: by smtp56.i.mail.ru with esmtpa (envelope-from ) id 1nDMcB-0005Sv-T4; Fri, 28 Jan 2022 11:28:16 +0300 Date: Fri, 28 Jan 2022 11:26:16 +0300 To: Igor Munkin Message-ID: References: <20210820154846.5515-1-skaplun@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9AA78FDF62ECAE61FBB8882B9C1ED1FCA269E871F1A847370182A05F538085040F5AC06CC77F1606BFC4CB492E83C64CE61473B8AEB1C55ADCB960995C3E824A2 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE72E4E5201E1C2E308EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006377EB37407B8EEC8CE8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D80B998DAD81A6AD0282F7847F56757F97117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18C26CFBAC0749D213D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B65D56369A3576CBA5089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5A8752286BAFD8D72F3C563E45A3514DF5B92D9A134DAD51ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA757165F9D92552535A410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D344888A9AABCDD3225D9F01A75E41E1BFA85ABDCCCF9EC16AB97F32708EFDC572BB674CFC7B5D285971D7E09C32AA3244CD062FEC2EDF15D425EAB29AF3C47FEFC7101BF96129E4011FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojqLK0kLh8sGcO9220+4cA4w== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB4B09326AFD62DA5867BAD14BC9AC152CFC83BDA1C32B41AC4F2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A84198E0F3ECE9B5443453F38A29522196 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Fix string.char() recording with no arguments. 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" Igor, Thanks for the review! On 28.01.22, Igor Munkin wrote: > Sergey, > > Thanks for the patch! Please consider my comments below. > > On 20.08.21, Sergey Kaplun wrote: > > From: Mike Pall > > > > (cherry picked from commit dfa692b746c9de067857d5fc992a41730be3d99a) > > > > `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 > > Typo: double space prior to "Hence". Fixed. > > > return from this call is recorded the framelink slot is used as a > > Strictly saying, this might be not the framelink slot. If you look onto > the trace dump, you'll see there is an SLOAD emitted for 12th stack > slot, but the framelink of the string.char (to be inlined on the trace) > is 11th AFAICS. So the loaded slot is just a garbage left after tap > initialization, or something else (though it definitely looks to be a > framelink earlier). See the artefacts of my investigation below. > > > As I've mentioned above, IR 0025 is SLOAD #12, and the 12th slot while > running the compiled trace is 0x400269e8 which was both base and top > slot for call, but wasn't not its framelink. It wasn't so > clear, since luajit-gdb.py dumps nothing if both base and top points to > a single slot. > > I propose to omit this framelink part and just mention that some garbage > can be loaded from stack as a result of recording in case > when no arguments are given. The new commit message is the following: =================================================================== Fix string.char() recording with no arguments. (cherry picked from commit dfa692b746c9de067857d5fc992a41730be3d99a) `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 =================================================================== > > > 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. > > I see no assertion running the test in Debug, unfortunately. Could you > please provide the way to hit it? I build as usual: | $ cmake . -DCMAKE_BUILD_TYPE=Debug -DLUA_USE_APICHECK=ON -DLUA_USE_ASSERT=ON && make -j and run this chunk (like test but simplier). | $ src/luajit -e ' | local results = {} | jit.opt.start("hotloop=1") | for _ = 1, 3 do | print(string.char()) | end | ' With the following result: | luajit: /home/burii/builds_workspace/luajit/gh-6371-string-char-no-arg/src/lj_record.c:137: rec_check_slots: Assertion `itype2irt(tv) == ((IRType)(((tr)>>24) & | IRT_TYPE))' failed. | Aborted (core dumped) But there are many ways to fail (for example on fold optimisation): | luajit: /home/burii/builds_workspace/luajit/gh-6371-string-char-no-arg/src/lj_opt_fold.c:2318: fold_fwd_sload: Assertion `J->slot[(&J->fold.ins)->op1] != 0' failed. > > > > > 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 > > --- > > > > Branch: https://github.com/tarantool/luajit/tree/skaplun/gh-6371-string-char-no-arg > > Issue: https://github.com/tarantool/tarantool/issues/6371 > > Tarantool branch: https://github.com/tarantool/tarantool/tree/skaplun/gh-6371-string-char-no-arg > > Side note: CI is totally red, but AFAICS it's unrelated with my patch. > > Side note: Try to rebase on the bleeding master, please. The updated tarantool branch: https://github.com/tarantool/tarantool/tree/skaplun/gh-6371-string-char-no-arg-full-ci > > > Side note: See also Changelog at the Tarantool branch. > > > > src/lj_ffrecord.c | 2 ++ > > .../gh-6371-string-char-no-arg.test.lua | 28 +++++++++++++++++++ > > 2 files changed, 30 insertions(+) > > create mode 100644 test/tarantool-tests/gh-6371-string-char-no-arg.test.lua > > > > diff --git a/src/lj_ffrecord.c b/src/lj_ffrecord.c > > index 8dfa80ed..be890a93 100644 > > --- a/src/lj_ffrecord.c > > +++ b/src/lj_ffrecord.c > > @@ -866,6 +866,8 @@ static void LJ_FASTCALL recff_string_char(jit_State *J, RecordFFData *rd) > > for (i = 0; J->base[i] != 0; i++) > > tr = emitir(IRT(IR_BUFPUT, IRT_PGC), tr, J->base[i]); > > J->base[0] = emitir(IRT(IR_BUFSTR, IRT_STR), tr, hdr); > > + } else if (i == 0) { > > + J->base[0] = lj_ir_kstr(J, &J2G(J)->strempty); > > } > > UNUSED(rd); > > } > > diff --git a/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua b/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua > > new file mode 100644 > > index 00000000..6df93f07 > > --- /dev/null > > +++ b/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua > > @@ -0,0 +1,28 @@ > > +local tap = require('tap') > > + > > +-- Test file to demonstrate assertion after `string.char()` > > +-- recording. > > +-- See also, https://github.com/tarantool/tarantool/issues/6371. > > + > > +local test = tap.test('gh-6371-string-char-no-arg') > > +-- XXX: Number of loop iterations. > > +-- 1, 2 -- instruction becomes hot > > +-- 3 -- trace is recorded (considering loop recording specifics), > > +-- but bytecodes are still executed via VM > > +-- 4 -- trace is executed, need to check that emitted mcode is > > +-- correct > > Minor: Strictly saying, this is not quite true. The right description is > the following: > * 1 -- instruction becomes hot. > * 2 -- recording of the loop body. > * 3 -- required for trace finalization, but this iteration runs the > generated mcode. NB: the issue doesn't occur, since execution leaves > the trace on table resizing guard. > * 4 -- reproduces the issue. > > Hence, if you allocate the table with necessary size (3 in our case), > then only 3 iterations are needed. Please adjust the comment above and > the code below. Fixed, thanks! See the iterative patch below. Branch is force-pushed. =================================================================== diff --git a/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua b/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua index 6df93f07..61d02101 100644 --- a/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua +++ b/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua @@ -6,11 +6,12 @@ local tap = require('tap') local test = tap.test('gh-6371-string-char-no-arg') -- XXX: Number of loop iterations. --- 1, 2 -- instruction becomes hot --- 3 -- trace is recorded (considering loop recording specifics), --- but bytecodes are still executed via VM --- 4 -- trace is executed, need to check that emitted mcode is --- correct +-- * 1 -- instruction becomes hot. +-- * 2 -- recording of the loop body. +-- * 3 -- required for trace finalization, but this iteration runs the +-- generated mcode. NB: the issue doesn't occur, since execution leaves +-- the trace on table resizing guard. +-- * 4 -- reproduces the issue. local NTEST = 4 test:plan(NTEST) =================================================================== > > > +local NTEST = 4 > > +test:plan(NTEST) > > + > > +-- Storage for the results to avoid trace aborting by `test:ok()`. > > +local results = {} > > +jit.opt.start('hotloop=1') > > +for _ = 1, NTEST do > > + table.insert(results, string.char()) > > +end > > + > > +for i = 1, NTEST do > > + test:ok(results[i] == '', 'correct recording of string.char() without args') > > +end > > + > > +os.exit(test:check() and 0 or 1) > > -- > > 2.31.0 > > > > -- > Best regards, > IM -- Best regards, Sergey Kaplun