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 023106755B5; Wed, 4 Sep 2024 18:02:15 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 023106755B5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1725462135; bh=CcPFpVhjOy3lZbK3lwfEE5sKSl+1XG5A1NgyGlmB8nM=; 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=EO6I8z1mLITm9u+OGv/5sA+x7WwON/6dM/S+9wY8Nx+XFWDUb86jTdycIOkU+UTQS hkp0qCuBCoykZvGSlh7mlZW1ysLTy4DKle7UEKnO8j626O3VXi76jFMtDPnGzNes6P 8mjHNzjl21MbIZXY9uEkRAlhJNSZLroO5iGiWras= Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [95.163.41.78]) (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 210E36755B5 for ; Wed, 4 Sep 2024 18:02:14 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 210E36755B5 Received: by smtp37.i.mail.ru with esmtpa (envelope-from ) id 1slrWO-0000000AMvS-3dwK; Wed, 04 Sep 2024 18:02:13 +0300 Date: Wed, 4 Sep 2024 18:02:06 +0300 To: Sergey Bronnikov Message-ID: References: <20240826102520.29541-1-skaplun@tarantool.org> <5af61bfe-8827-40b4-b69c-17b5dd67a58f@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5af61bfe-8827-40b4-b69c-17b5dd67a58f@tarantool.org> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD987C31DA0ECC3DFE2A266CEA4CC0B0306473EAB0233F362AF182A05F5380850404C228DA9ACA6FE27A3E47765194D24FAC591814E25D11F9FD63AD7F8D3A6E0FC50769EBDF50973D8FEA245EA6D08AB3D X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7233EAFDDCC869EB0EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378957B77C126D2D948638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D84287EFCFBE997E0867875DBA7CE4285B95151A03A14C3DA1CC7F00164DA146DAFE8445B8C89999728AA50765F7900637F6B57BC7E64490618DEB871D839B7333395957E7521B51C2DFABB839C843B9C08941B15DA834481F8AA50765F790063793270F7220657A0A389733CBF5DBD5E9B5C8C57E37DE458B9E9CE733340B9D5F3BBE47FD9DD3FB595F5C1EE8F4F765FC72CEEB2601E22B093A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E7358CCB3ED2A1DE2304C4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A58DB923548E12953A5002B1117B3ED6969359BF9051A49E6DAD0703CEB2EF9A27823CB91A9FED034534781492E4B8EEADF5E532225D4D775BBDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF139717D08F8E4F60B96DE251693167F20117075F42800FD0830444E2F9F684F5EBEAAAAF261D74163EE79E6E40FF695065CB0DFFAAC7E50A2B117344E781DA6355EAF08702347E295F4332CA8FE04980913E6812662D5F2A5EAB5682573093F7837F15F2B5E4A70B33F2C28C22F508233FCF178C6DD14203 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojpeIfmLQPsUL+StG89EUCIQ== X-DA7885C5: C755AA2086F1D307F255D290C0D534F9E442A440DE7F3A85CEFA5E6BF0F5C1D07E40513B020D6C1D5B1A4C17EAA7BC4BEF2421ABFA55128DAF83EF9164C44C7E X-Mailru-Sender: 689FA8AB762F7393C6D0B12EA33CAA9BF0DA8E88C72D10194CD7C42E7A952EC3CFD61C2C15BD1E18E49D44BB4BD9522A059A1ED8796F048DB274557F927329BE89D5A3BC2B10C37545BD1C3CC395C826B4A721A3011E896F X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Limit number of string format elements to compile. 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! See my answers below. On 04.09.24, Sergey Bronnikov wrote: > Hi, Sergey, > > thanks for the patch! > > See my comments below. > > Sergey > > On 26.08.2024 13:25, Sergey Kaplun wrote: > > From: Mike Pall > > > > Reported by pwnhacker0x18. > > > > (cherry picked from commit 4fc48c50fe3f3f5a9680bada5c0c0d0d7eb345a3) > > > > When compiling `string.format()` with a huge sequence of elements, it is > > possible that too many KGC IRs underflow the IR buffer. This patch > > limits the maximum number of `string.format()` elements to be compiled > > to 100. > > > > Sergey Kaplun: > > * added the description and the test for the problem > > > > Part of tarantool/tarantool#10199 > > --- > > > > Branch:https://github.com/tarantool/luajit/tree/skaplun/lj-1203-limit-format-elements > > Related issues: > > *https://github.com/tarantool/tarantool/issues/10199 > > *https://github.com/LuaJIT/LuaJIT/issues/1203 > > > > src/lj_ffrecord.c | 2 ++ > > .../lj-1203-limit-format-elements.test.lua | 28 +++++++++++++++++++ > > 2 files changed, 30 insertions(+) > > create mode 100644 test/tarantool-tests/lj-1203-limit-format-elements.test.lua > > > > diff --git a/src/lj_ffrecord.c b/src/lj_ffrecord.c > > index d5fc081e..3b82d044 100644 > > --- a/src/lj_ffrecord.c > > +++ b/src/lj_ffrecord.c > > @@ -962,6 +962,7 @@ static void LJ_FASTCALL recff_string_format(jit_State *J, RecordFFData *rd) > > TRef hdr, tr; > > FormatState fs; > > SFormat sf; > > + int nfmt = 0; > > /* Specialize to the format string. */ > > emitir(IRTG(IR_EQ, IRT_STR), trfmt, lj_ir_kstr(J, fmt)); > > tr = hdr = recff_bufhdr(J); > > @@ -1031,6 +1032,7 @@ static void LJ_FASTCALL recff_string_format(jit_State *J, RecordFFData *rd) > > recff_nyiu(J, rd); > > return; > > } > > + if (++nfmt > 100) lj_trace_err(J, LJ_TRERR_TRACEOV); > > } > > J->base[0] = emitir(IRT(IR_BUFSTR, IRT_STR), tr, hdr); > > } > > diff --git a/test/tarantool-tests/lj-1203-limit-format-elements.test.lua b/test/tarantool-tests/lj-1203-limit-format-elements.test.lua > > new file mode 100644 > > index 00000000..f17d4e37 > > --- /dev/null > > +++ b/test/tarantool-tests/lj-1203-limit-format-elements.test.lua > > @@ -0,0 +1,28 @@ > > +local tap = require('tap') > > + > > +-- Test file to demonstrate LuaJIT incorrect recording of > > +-- `string.format()` function with huge amount of elements. > > +-- See also:https://github.com/LuaJIT/LuaJIT/issues/1173. > Seems a correct link is https://github.com/LuaJIT/LuaJIT/issues/1203 Fixed, thanks! Branch is force-pushed. =================================================================== diff --git a/test/tarantool-tests/lj-1203-limit-format-elements.test.lua b/test/tarantool-tests/lj-1203-limit-format-elements.test.lua index f17d4e37..bf250000 100644 --- a/test/tarantool-tests/lj-1203-limit-format-elements.test.lua +++ b/test/tarantool-tests/lj-1203-limit-format-elements.test.lua @@ -2,7 +2,7 @@ local tap = require('tap') -- Test file to demonstrate LuaJIT incorrect recording of -- `string.format()` function with huge amount of elements. --- See also: https://github.com/LuaJIT/LuaJIT/issues/1173. +-- See also: https://github.com/LuaJIT/LuaJIT/issues/1203. local test = tap.test('lj-1203-limit-format-elements'):skipcond({ ['Test requires JIT enabled'] = not jit.status(), =================================================================== > > + > > +local test = tap.test('lj-1203-limit-format-elements'):skipcond({ > > + ['Test requires JIT enabled'] = not jit.status(), > > +}) > > + > > +test:plan(2) > > + > > +jit.opt.start('hotloop=1') > > + > > +-- XXX: Use a huge amount of format elements to process, which > > +-- creates a lot of string constants. > > +local NELEMENTS = 25000 > > Why 25000? It is reproduced with 10000 as well. It is flaky-reproducible with less amount inside our test suite (at least on my laptop), so I prefer to keep this number of elements. > > > > +local fmt = ('%'):rep(NELEMENTS * 2) > > +local expected = ('%'):rep(NELEMENTS) > > +local result > > +for _ = 1, 4 do > > + result = fmt:format() > > +end > > + > > +test:ok(true, 'no IR buffer underflow') > Why do you need this check? Why the following check it not enough? We usually check both (no assertion and correctness) where it is easily done. > > +test:is(result, expected, 'correct result') > > + > > +test:done(true) -- Best regards, Sergey Kaplun