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 965756ECE3; Tue, 23 Nov 2021 15:57:55 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 965756ECE3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1637672275; bh=kmLFAzse5C2pfOXoRX7MdfmScPt+9uKVWzdvOFa+API=; 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=ZfEub3zS1exGkhFT5nGgJ6P1t4yBS4dCHVqnA6A/EH3RHLsiLF2BrrNxtrdvvZQC/ IzihuVayBTWl9MPbuldG9NIocxhAY+sye+/545cnBEhwXUTjEQzf5sMlBblhxKvyca pJsjjpuw2OsFtc5BNM1cI0c3E87kz/yP3R9BhBFM= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 43C836ECE3 for ; Tue, 23 Nov 2021 15:57:53 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 43C836ECE3 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mpVMu-00069K-4v; Tue, 23 Nov 2021 15:57:52 +0300 Date: Tue, 23 Nov 2021 15:57:21 +0300 To: Sergey Kaplun Message-ID: References: <20211102160844.GF8831@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9FE0487E502468146B8787A579DD4BF53FBE1400F6FA43E0D182A05F538085040C2CBAFBC2464DD6668C3EB917E7FCB1C1291F10517FC3247771F5DCF233E8B77 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7AB524098FB2F2222EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637C83F54BD885518138638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D82EAF62ED9536EF8371A62CEACFAF1CB8117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC2EE5AD8F952D28FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6753C3A5E0A5AB5B7089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A555412DA61AC29156DCAAD62460BB228F2B1D46C2EDC128E2D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA759F66ED85EB5F25FD410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34197948450CB5442A1EE6AD7B7CE9CA15FA3FF8B9C10ABBE91E67E4E47347B56B0FC8F7847C16DD3F1D7E09C32AA3244CBA7BDF992A2913F01D924E009C8B750160759606DA2E136A927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojutWt0++zX5RJ4jNqfQ4PZA== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5DA9230DB36DEE8959CBE84DC1B1F39183A7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Fix frame traversal for __gc handler frames. 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: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey has already sent v2[1], but I decided to leave a few notes for the history here. On 08.11.21, Sergey Kaplun wrote: > Igor, > > Thanks for the review! > > On 02.11.21, Igor Munkin wrote: > > > > > diff --git a/test/tarantool-tests/lj-601-fix-gc-finderrfunc.test.lua b/test/tarantool-tests/lj-601-fix-gc-finderrfunc.test.lua > > > > > new file mode 100644 > > > > > index 00000000..d8d79100 > > > > > --- /dev/null > > > > > +++ b/test/tarantool-tests/lj-601-fix-gc-finderrfunc.test.lua > > > > > > > > Unfortunately the test passes on the ’tarantool’ branch > > > > > > > > s-ostanevich:luajit s.ostanevich$ git checkout tarantool > > > > Switched to branch 'tarantool' > > > > s-ostanevich:luajit s.ostanevich$ git clean -xdff > > > > […] > > > > s-ostanevich:luajit s.ostanevich$ cmake . > > > > […] > > > > s-ostanevich:luajit s.ostanevich$ make > > > > […] > > > > [100%] Built target libluajit_shared > > > > [100%] Built target libluajit > > > > [100%] Built target luajit > > > > s-ostanevich:luajit s.ostanevich$ git checkout skaplun/lj-601-fix-gc-finderrfunc > > > > s-ostanevich:luajit s.ostanevich$ cd test/tarantool-tests > > > > s-ostanevich:tarantool-tests s.ostanevich$ ../../src/luajit lj-601-fix-gc-finderrfunc.test.lua > > > > TAP version 13 > > > > 1..1 > > > > ok - successfully collectgarbage with error > > > > > > Wild guess: it doesn't fail on Mac due to GC64 ;). > > > See CI [1] to check my hypothesis. > > > > Is it possible to fix the test chunk making it check the error even with > > GC64 enabled? > > Yes, may be, but it is hard to forecast its behaviour: > We need to generate some garbage on the C stack to be used as an errfunc > value from the unprotected C frame suggested as C protected frame (since > `cframe_prev()` unwinding is missing for C protected frame (*). > > (*) I.e. C frames are the following CP|C|CP and during handling the second > CP frame in finderrfunc we return the errfunc for the unprotected C > frame. In v2[1] Sergey provided a test where the desired stack layout is made via Lua C API and garbage is generated with the area allocated on the host stack. As a result the test also unconditionally fails with GC64 mode enabled (when the patch is not applied, obviously). > > > > > > +getmetatable(a).__gc = function() > > > > > + -- Function to raise error via `lj_err_run()` inside __gc. > > > > What does exactly raise an error in this function? > > `collectgarbage()` returns number and attemt to call this number raises > an error. PEBKAC, I totally forgot what function does :) > > > > > > > > + local _ = load(function() collectgarbage()() end) > > > > > +end > > > > > + > > > > > +-- XXX: Generate a small bunch of proxies. Need several to call > > > > > +-- `collectgarbage()` on another proxy inside __gc. N cycles is > > > > > +-- empirical number. > > > > Why do you even need this loop? Why can't you just assign nil to ? > > We need to create a chain with C|CP frames to use errfunction value > (that is garbage) from C frame as it was from C protected frame. > Add the corresponding comment. Again, this chain is created with no loop at all but via Lua C in v2[1]. > > > Side note: 4 cycles is not enough sometimes (test is flaky) -- change > them to 6. See no false positives oks after the changes without fix. AFAICS this value can vary from 4 to 10000 depending on the number of garbage to be collected. This was the main reason to reimplement the test, since it was more a reproducer rather than a good test. > > > -- > Best regards, > Sergey Kaplun [1]: https://lists.tarantool.org/tarantool-patches/20211119164157.18344-1-skaplun@tarantool.org/ -- Best regards, IM