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 C3C901B6B05B; Wed, 4 Mar 2026 18:40:17 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C3C901B6B05B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1772638817; bh=+mZlOrWH4eW+jn8gF7vEDP2fm3lPb6pj4X8oYNQXI6M=; 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=uZzShWOvNSZNuUzaB86dMMLjURNyitwBHz9i6NK2srtyuJlOYI88kgaoARdu5qbEe SebJnqBipjgLoobg+hsjJ6sMhyRSr7Miz6ueEdgdAJvs5QnSssvdKcLIBkcdY+S2ec 7MqH7y7AaLMQh8dXh3pAoyh8/2sGI4roI+HDRpNs= Received: from send80.i.mail.ru (send80.i.mail.ru [89.221.237.175]) (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 2E1B61B6B05A for ; Wed, 4 Mar 2026 18:40:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2E1B61B6B05A Received: by exim-smtp-558f87dcd7-gtnwp with esmtpa (envelope-from ) id 1vxoKc-00000000J1p-3w09; Wed, 04 Mar 2026 18:40:15 +0300 Content-Type: multipart/alternative; boundary="------------l7kyyfaliDoilmjR2aXVKMp7" Message-ID: Date: Wed, 4 Mar 2026 18:40:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org References: <1d2c3bbc66be0d8d2049f0b7605b9ce111df37fa.1772438261.git.skaplun@tarantool.org> In-Reply-To: <1d2c3bbc66be0d8d2049f0b7605b9ce111df37fa.1772438261.git.skaplun@tarantool.org> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9406AA218EDC7AA27529648CD77E6EDF89565B055363D9479182A05F538085040B3953B2B529C19D13DE06ABAFEAF67058F40586BB6CE1C6B966BD4ABA0B7834AA24CDA786A8AA87E X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7E9A0F80F179600C6EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637AC83A81C8FD4AD23D82A6BABE6F325AC2E85FA5F3EDFCBAA7353EFBB55337566CF7C7957E47253288B128865504730D1687D36DB7901A6B08B93081F0A5F08D6389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0DEC8C2C8BCD2534D8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6E5E764EB5D94DBD4CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8D32BA5DBAC0009BE9E8FC8737B5C2249E1AEA437FA109C1B76E601842F6C81A12EF20D2F80756B5FB606B96278B59C4276E601842F6C81A127C277FBC8AE2E8BF6CC78C53FAB0F773AA81AA40904B5D99C9F4D5AE37F343AD1F44FA8B9022EA23BBE47FD9DD3FB595F5C1EE8F4F765FC72CEEB2601E22B093A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E7356436AE5DD6441DC7C4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A53AA929FC3E8B10ED5002B1117B3ED6962F4D2E30976488BB559C6C5561145D6F823CB91A9FED034534781492E4B8EEADEEA082C9A12FE455BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0AD73CAD6646DEDE191716CD42B3DD1D34CAB70F9BE574AE9C625B6776AC983F447FC0B9F89525902EE6F57B2FD27647F25E66C117BDB76D659ED16CA917D105A84DB8D747743DA1504F47016D4788EC533042DAB8047EE855EE6F5931225F5296BB8341EE9D5BE9A0AD7F1D66016E50AB9B715E6703CB17BACC8AD541003DCA6598CD93680B12512CF4C41F94D744909CE2512F26BEC029E55448553D2254B8D95CD72808BE417F3B9E0E7457915DAA85F X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu53w8ahmwBjZKM/YPHZyZHvz5uv+WouB9+ObcCpyrx6l7KImUglyhkEat/+ysWwi0gdhEs0JGjl6ggRWTy1haxBpVdbIX1nthFXMZebaIdHP2ghjoIc/363UZI6Kf1ptIMVbwN8XFWZxQUcaIPwqwIjj0= X-Mailru-Sender: C4F68CFF4024C8867DFDF7C7F25884584020E490DEA930977FC47A557B39A39BF275DB11951B03FA94E9A093BA7D1E92645D15D82EE4B272BD6E4642A116CA93524AA66B5ACBE6721EF430B9A63E2A504198E0F3ECE9B5443453F38A29522196 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 2/2] x64/!LJ_GC64: The allocation limit is required for a no-JIT build, too. 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" This is a multi-part message in MIME format. --------------l7kyyfaliDoilmjR2aXVKMp7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Sergey, thanks for the patch! LGTM Sergey On 3/2/26 11:05, Sergey Kaplun wrote: > From: Mike Pall > > Thanks to Sergey Kaplun. > > (cherry picked from commit eff4006837792b6105e0a1743283ddde3548fc09) > > For the non-GC64 build with disabled JIT, LuaJIT's internal allocator > may return 32-bit addresses. This may lead to the assertion failure > during the reallocation of the array part of the table or to the crash > (if assertions are disabled) due to an incorrect arithmetic in the x86 > VM. For example, the addition with a 32-bit wide address may overflow > in TSETV or TGETV and cause the crash. > > This patch sets the allocation limit for the build without JIT. > > Sergey Kaplun: > * added the description and the test for the problem > > Part of tarantool/tarantool#12134 > --- > src/lj_alloc.c | 4 +- > .../lj-1430-internal-alloc-limit.test.lua | 39 +++++++++++++++++++ > 2 files changed, 41 insertions(+), 2 deletions(-) > create mode 100644 test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua > > diff --git a/src/lj_alloc.c b/src/lj_alloc.c > index f82c9854..97eb94d2 100644 > --- a/src/lj_alloc.c > +++ b/src/lj_alloc.c > @@ -99,8 +99,8 @@ > > #if LJ_GC64 > #define LJ_ALLOC_MBITS 47 /* 128 TB in LJ_GC64 mode. */ > -#elif LJ_TARGET_X64 && LJ_HASJIT > -/* Due to limitations in the x64 compiler backend. */ > +#elif LJ_TARGET_X64 > +/* Due to limitations in the x64 non-GC64 VM. */ > #define LJ_ALLOC_MBITS 31 /* 2 GB on x64 with !LJ_GC64. */ > #else > #define LJ_ALLOC_MBITS 32 /* 4 GB on other archs with !LJ_GC64. */ > diff --git a/test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua b/test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua > new file mode 100644 > index 00000000..969d26d6 > --- /dev/null > +++ b/test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua > @@ -0,0 +1,39 @@ > +local tap = require('tap') > + > +-- Test file to demonstrate incorrect allocation limit for the > +-- non-GC64 build with disabled JIT. > +-- See also:https://github.com/LuaJIT/LuaJIT/issues/1430. > + > +local test = tap.test('lj-1430-internal-alloc-limit') > + > +test:plan(1) > + > +-- This function creates a bunch of long array-like tables. > +-- Eventually for one of the tables the address of the array > +-- element will not fit in the 31-bit range, causing the incorrect > +-- arithmetic inside the VM and a crash or assertion failure > +-- during the reallocation. > +local function test_payload() > + local POOL_SZ = 8 > + -- luacheck: no unused > + local pools = {} > + for i = 1, POOL_SZ do > + pools[i] = {} > + end > + > + local v = 1 > + for j = 1, POOL_SZ do > + for i = 1, 0x2000000 do > + pools[j][i] = v > + end > + end > +end > + > +-- Protect the call to avoid the OOM. > +pcall(test_payload) > + > +-- Free memory for the TAP tests. > +collectgarbage() > + > +test:ok(true, 'no crash or assertion failure') > +test:done(true) --------------l7kyyfaliDoilmjR2aXVKMp7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi, Sergey,

thanks for the patch! LGTM

Sergey

On 3/2/26 11:05, Sergey Kaplun wrote:
From: Mike Pall <mike>

Thanks to Sergey Kaplun.

(cherry picked from commit eff4006837792b6105e0a1743283ddde3548fc09)

For the non-GC64 build with disabled JIT, LuaJIT's internal allocator
may return 32-bit addresses. This may lead to the assertion failure
during the reallocation of the array part of the table or to the crash
(if assertions are disabled) due to an incorrect arithmetic in the x86
VM. For example, the addition with a 32-bit wide address may overflow
in TSETV or TGETV and cause the crash.

This patch sets the allocation limit for the build without JIT.

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#12134
---
 src/lj_alloc.c                                |  4 +-
 .../lj-1430-internal-alloc-limit.test.lua     | 39 +++++++++++++++++++
 2 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua

diff --git a/src/lj_alloc.c b/src/lj_alloc.c
index f82c9854..97eb94d2 100644
--- a/src/lj_alloc.c
+++ b/src/lj_alloc.c
@@ -99,8 +99,8 @@
 
 #if LJ_GC64
 #define LJ_ALLOC_MBITS		47	/* 128 TB in LJ_GC64 mode. */
-#elif LJ_TARGET_X64 && LJ_HASJIT
-/* Due to limitations in the x64 compiler backend. */
+#elif LJ_TARGET_X64
+/* Due to limitations in the x64 non-GC64 VM. */
 #define LJ_ALLOC_MBITS		31	/* 2 GB on x64 with !LJ_GC64. */
 #else
 #define LJ_ALLOC_MBITS		32	/* 4 GB on other archs with !LJ_GC64. */
diff --git a/test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua b/test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua
new file mode 100644
index 00000000..969d26d6
--- /dev/null
+++ b/test/tarantool-tests/lj-1430-internal-alloc-limit.test.lua
@@ -0,0 +1,39 @@
+local tap = require('tap')
+
+-- Test file to demonstrate incorrect allocation limit for the
+-- non-GC64 build with disabled JIT.
+-- See also: https://github.com/LuaJIT/LuaJIT/issues/1430.
+
+local test = tap.test('lj-1430-internal-alloc-limit')
+
+test:plan(1)
+
+-- This function creates a bunch of long array-like tables.
+-- Eventually for one of the tables the address of the array
+-- element will not fit in the 31-bit range, causing the incorrect
+-- arithmetic inside the VM and a crash or assertion failure
+-- during the reallocation.
+local function test_payload()
+  local POOL_SZ = 8
+  -- luacheck: no unused
+  local pools = {}
+  for i = 1, POOL_SZ do
+    pools[i] = {}
+  end
+
+  local v = 1
+  for j = 1, POOL_SZ do
+    for i = 1, 0x2000000 do
+      pools[j][i] = v
+    end
+  end
+end
+
+-- Protect the call to avoid the OOM.
+pcall(test_payload)
+
+-- Free memory for the TAP tests.
+collectgarbage()
+
+test:ok(true, 'no crash or assertion failure')
+test:done(true)
--------------l7kyyfaliDoilmjR2aXVKMp7--