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 A95136FA3A5; Fri, 24 Nov 2023 15:30:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org A95136FA3A5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1700829021; bh=6++xUV8tZ96aZY8lVVsSaemFOFqOhKDI96BpBrviNOk=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=nEuGEftlr0vhetVqsQOWZjhjtpzUiF/7i2EWeFiSnqEDhIdnFmKHD0oWgPgo8oLr8 yjXOskAxy+Zm6esvYxSzYh0gkIYeDj7XneV9vRIfkZxnHoPDKbzEDbEC7UXhY7us0K KlU9xN5kya0inmGRFDtyFh3ii1w84oCBspIBAq3s= Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [95.163.41.73]) (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 1E7A16CB2C1 for ; Fri, 24 Nov 2023 15:30:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1E7A16CB2C1 Received: by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1r6VK8-000ikd-0x; Fri, 24 Nov 2023 15:30:20 +0300 Message-ID: Date: Fri, 24 Nov 2023 15:30:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Maksim Kokryashkin , tarantool-patches@dev.tarantool.org, skaplun@tarantool.org, m.kokryashkin@tarantool.org References: <20231122143534.11330-1-max.kokryashkin@gmail.com> <20231122143534.11330-3-max.kokryashkin@gmail.com> In-Reply-To: <20231122143534.11330-3-max.kokryashkin@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD91D460360092162742EFEF7C1994BA156629E77E797DCFC85182A05F5380850402D2F117BBB5A7FD203D50DE61FBA09A2A50CAA1AE6B76862A7870383FFB3D2DD X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7BC08626EA5717D14EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637F898CA578D17CA188638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8E34E5AB57A1E0C86CE3A7C10432D87DE117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD186FD1C55BDD38FC3FD2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE26055571C92BF10F4AAC223A686B1DECD8FC6C240DEA76429C9F4D5AE37F343AA9539A8B242431040A6AB1C7CE11FEE36089696B24BB1D192D242C3BD2E3F4C6C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947CD2DCF9CF1F528DBC2E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89F00AD5422731CA18C57739F23D657EF2BB5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A57C3369DF6A3F76BF9233E1954237FC5D5ADE586EA7C16CD0F87CCE6106E1FC07E67D4AC08A07B9B0B355ED1E20F5346ACB5012B2E24CD356 X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF84C791CE9E543C252B90B97E8B7D45DDEB2ECD6EAE99D8E392B7AE5C2C8B857E35D245DF744597F16E159192F517E6716B0F35B58F6A54D81C451DA58FA14A81A74DFFEFA5DC0E7F02C26D483E81D6BE0DBAE6F56676BC7117BB6831D7356A2DEC5B5AD62611EEC62B5AFB4261A09AF0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojXb+1cQU8cAOcg17zS9MOTA== X-Mailru-Sender: 11C2EC085EDE56FAC07928AF2646A76914347945B0594EE103D50DE61FBA09A2BA0848438379BFCEEBA65886582A37BD66FEC6BF5C9C28D98A98C1125256619760D574B6FC815AB872D6B4FCE48DF648AE208404248635DF X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit v3 2/3] Cleanup stack overflow handling. 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" Hello, Max thanks for the patch! See a couple of minor comments below Sergey On 11/22/23 17:35, Maksim Kokryashkin wrote: > From: Mike Pall > > Reported by Peter Cawley. > > (cherry-picked from commit d2f6c55b05c716e5dbb479b7e684abaee7cf6e12) > > After the previous patch, it is possible to trigger the > `stack overflow` error prematurely. Consider the following > situation: there are already 33000 slots allocated on a Lua > stack, and then there are 30 additional slots needed. In this > case, the actual allocated amount would be twice the already > allocated size, shrunk to the `LJ_STACK_MAXEX` size, which > would lead to the stack overflow error, despite the fact there > is plenty of unused space. This patch completely reworks the > logic of error handling during stack growth to address the issue. > > Another important thing to notice is that the `LJ_ERR_STKOV` is > thrown only if the `L->status` is `LUA_OK` and that status is set > to `LUA_ERRRUN` just before throwing the error. The status is set > to `LUA_ERRRUN` to avoid the second stack overflow during the > `err_msgv` execution. > > Maxim Kokryashkin: > * added the description and the test for the problem > > Part of tarantool/tarantool#9145 > --- > src/lj_state.c | 15 +++-- > .../lj-962-premature-stack-overflow.test.c | 63 +++++++++++++++++++ > 2 files changed, 74 insertions(+), 4 deletions(-) > create mode 100644 test/tarantool-c-tests/lj-962-premature-stack-overflow.test.c > > diff --git a/src/lj_state.c b/src/lj_state.c > index 76153bad..d8a5134c 100644 > --- a/src/lj_state.c > +++ b/src/lj_state.c > @@ -121,8 +121,17 @@ void lj_state_shrinkstack(lua_State *L, MSize used) > void LJ_FASTCALL lj_state_growstack(lua_State *L, MSize need) > { > MSize n; > - if (L->stacksize > LJ_STACK_MAXEX) /* Overflow while handling overflow? */ > - lj_err_throw(L, LUA_ERRERR); > + if (L->stacksize >= LJ_STACK_MAXEX) { > + /* 4. Throw 'error in error handling' when we are _over_ the limit. */ > + if (L->stacksize > LJ_STACK_MAXEX) > + lj_err_throw(L, LUA_ERRERR); /* Does not invoke an error handler. */ > + /* 1. We are _at_ the limit after the last growth. */ > + if (!L->status) { /* 2. Throw 'stack overflow'. */ > + L->status = LUA_ERRRUN; /* Prevent ending here again for pushed msg. */ > + lj_err_msg(L, LJ_ERR_STKOV); /* May invoke an error handler. */ > + } > + /* 3. Add space (over the limit) for pushed message and error handler. */ > + } > n = L->stacksize + need; > if (n > LJ_STACK_MAX) { > n += 2*LUA_MINSTACK; > @@ -132,8 +141,6 @@ void LJ_FASTCALL lj_state_growstack(lua_State *L, MSize need) > n = LJ_STACK_MAX; > } > resizestack(L, n); > - if (L->stacksize >= LJ_STACK_MAXEX) > - lj_err_msg(L, LJ_ERR_STKOV); > } > > void LJ_FASTCALL lj_state_growstack1(lua_State *L) > diff --git a/test/tarantool-c-tests/lj-962-premature-stack-overflow.test.c b/test/tarantool-c-tests/lj-962-premature-stack-overflow.test.c > new file mode 100644 > index 00000000..12cb9004 > --- /dev/null > +++ b/test/tarantool-c-tests/lj-962-premature-stack-overflow.test.c > @@ -0,0 +1,63 @@ > +#include "lua.h" > +#include "lauxlib.h" > + > +#include "test.h" > +#include "utils.h" > + > +/* > + * XXX: The "lj_obj.h" header is included to calculate the > + * number of stack slots used from the bottom of the stack. > + */ > +#include "lj_obj.h" > + > +static int cur_slots = -1; > + > +static int fill_stack(lua_State *L) > +{ > + cur_slots = L->base - tvref(L->stack); > + > + while(lua_gettop(L) < LUAI_MAXSTACK) { > + cur_slots += 1; > + lua_pushinteger(L, 42); > + } > + > + return 0; > +} > + > +static int premature_stackoverflow(void *test_state) > +{ > + lua_State *L = test_state; > + lua_cpcall(L, fill_stack, NULL); > + assert_true(cur_slots == LUAI_MAXSTACK - 1); > + return TEST_EXIT_SUCCESS; > +} > + this testcase should fail with reverted patch, right? but it is not > +/* > + * XXX: This test should fail neither before the patch > + * nor after it. I propose to say about it in commit message. We have a rule that test must fail without backported patch, so passed test is unexpected here. > + */ > +static int stackoverflow_during_stackoverflow(void *test_state) > +{ > + lua_State *L = test_state; > + /* > + * XXX: `fill_stack` acts here as its own error handler, > + * causing the second stack overflow. > + */ > + lua_pushcfunction(L, fill_stack); > + lua_pushcfunction(L, fill_stack); > + int status = lua_pcall(L, 0, 0, -2); > + assert_true(status == LUA_ERRERR); > + return TEST_EXIT_SUCCESS; > +} > + > +int main(void) > +{ > + lua_State *L = utils_lua_init(); > + const struct test_unit tgroup[] = { > + test_unit_def(premature_stackoverflow), > + test_unit_def(stackoverflow_during_stackoverflow), > + }; > + const int test_result = test_run_group(tgroup, L); > + utils_lua_close(L); > + return test_result; > +}