From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Maksim Kokryashkin <max.kokryashkin@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit v2 1/2] Print errors from __gc finalizers instead of rethrowing them. Date: Wed, 8 Nov 2023 11:21:12 +0300 [thread overview] Message-ID: <ZUtE-Hy6hGePdHqI@root> (raw) In-Reply-To: <20231107210616.53138-2-max.kokryashkin@gmail.com> Hi, Maksim! Thanks for the fixes! LGTM, just some minor nits below. On 08.11.23, Maksim Kokryashkin wrote: > From: Mike Pall <mike> > > Finalizers are not supposed to throw errors -- this is undefined behavior. > Lua 5.1 - 5.3 and (previously) LuaJIT rethrow the error. This randomly > breaks some unrelated code that just happens to do an allocation. Bad. > Lua 5.4 catches the error and emits a warning instead. But warnings are > not enabled by default, so it fails silently. Even worse. > LuaJIT (now) catches the error and emits a VM event. The default event > handler function prints "ERROR in finalizer: ...". > Set a custom handler function with: jit.attach(handler, "errfin") > > (cherry-picked from commit 1c279127050e86e99970100e9c42e0f09cd54ab7) > > The default handler for finalizer errors is set during the > Lua initialization. Namely, in the `luaL_newstate`. > > Along with the introduction of the new `ERRFIN` VM event, the high > bits for the old VM events are removed since they are scratched > anyway by the bitwise operation `(hash)<<3` in the `VMEVENT_DEF` > macro. > > This patch results in a regression in the PUC-Rio test suite. The > test in the suite for the error in the GC finalizer fails after > the patch because the error is now handled with the VM event > handler instead of being rethrown. Hence, the `collectgarbage` > finishes successfully despite the error in the GC finalizer. > Considering this change, the test was disabled. > > There is also another regression in the `misclib-getmetrics-capi`, > because there are a few test cases reliant on the `lua_gettop(L)` > value, which is broken after this patch. The `_VMEVENTS` table, > where the error handler for GC finalizers is set, was not cleared > from the stack after the initialization. This issue is fixed in > the following patch. > > Maxim Kokryashkin: > * added the test for the problem and the description for the patch > > Part of tarantool/tarantool#9145 > --- > Q: > >> +-- The test below is disabled for LuaJIT, since it handles errors from > >> +-- GC finalizers via VM event. > >> -- errors during collection > >> -u = newproxy(true) > >> -getmetatable(u).__gc = function () error "!!!" end > >> -u = nil > >> -assert(not pcall(collectgarbage)) > >> - > >> +-- u = newproxy(true) > >> +-- getmetatable(u).__gc = function () error "!!!" end > >> +-- u = nil > >> +-- assert(not pcall(collectgarbage)) > >> > > > >Maybe its better just to setup the "errfin" handler to `error()` function? > > A: Well, that is not going to fix the test case anyway. See, the > `lj_vmevent_call` is a protected call and any errros which happened > during the vmevent handling are silently printed into the stderr. So > the collectgarbage call here won't fail even in this case. OK, lets left it as is. > > Q: > >> +local function errfin_handler() > >> + error_in_finalizer = true > >> +end > > > >Is it better just to add `test:ok(true, 'error handler called')` here? > > A: Nope, because I want to test not only that there is no error, but > also that the finalizer error handler was called. So, the test will be passed, if the `errfin_handler()` is called. If it isn't, we got bad plan error, so test fails. As a bonus, we check that handler is called only once for each error :). > > > Q: I suggest to test the default handler too, within the separate test. > > Also, maybe we should test other cases (error function (in default > case), function with tailcall to error, etc.), any ideas about them? > > A: I've added a test for the default handler. I doubt that testing > for other cases you have mentioned is meaningful, because all of > these errors are going to be silently printed into the stderr. OK, thanks! > > src/Makefile.dep.original | 14 +++---- > src/lib_aux.c | 33 ++++++++++++++- > src/lj_gc.c | 10 ++++- > src/lj_vmevent.h | 7 ++-- > test/PUC-Rio-Lua-5.1-tests/gc.lua | 12 +++--- > ...6-print-errors-from-gc-fin-custom.test.lua | 42 +++++++++++++++++++ > ...-print-errors-from-gc-fin-default.test.lua | 11 +++++ > .../script.lua | 24 +++++++++++ > 8 files changed, 133 insertions(+), 20 deletions(-) > create mode 100644 test/tarantool-tests/lj-946-print-errors-from-gc-fin-custom.test.lua > create mode 100644 test/tarantool-tests/lj-946-print-errors-from-gc-fin-default.test.lua > create mode 100644 test/tarantool-tests/lj-946-print-errors-from-gc-fin-default/script.lua > <snipped> > diff --git a/test/tarantool-tests/lj-946-print-errors-from-gc-fin-custom.test.lua b/test/tarantool-tests/lj-946-print-errors-from-gc-fin-custom.test.lua > new file mode 100644 > index 00000000..71efc260 > --- /dev/null > +++ b/test/tarantool-tests/lj-946-print-errors-from-gc-fin-custom.test.lua > @@ -0,0 +1,42 @@ > +local tap = require('tap') > +local test = tap.test('lj-946-print-errors-from-gc-fin-custom'):skipcond({ > + ['Test requires JIT enabled'] = not jit.status(), > +}) > + > +test:plan(2) > + > +local ffi = require('ffi') > +local error_in_finalizer = false > + > +local function errfin_handler() > + error_in_finalizer = true > +end > + > +local function new_bad_cdata() > + return ffi.gc(ffi.new('char [?]', 1024), 'uncallable string') > +end > + > +local function test_f() > + collectgarbage('collect') > + -- Make GC aggressive enough to end the atomic phase before > + -- exiting the trace. > + collectgarbage('setstepmul', 400) > + -- The number of iterations is empirical, just big enough for the Nit: comment line length is more than 66 symbols. > + -- issue to strike. > + for _ = 1, 4000 do > + new_bad_cdata() > + end > +end > + > +jit.opt.start('hotloop=1') > +-- Handler is registered but never called before the patch. > +-- It should be called after the patch. > +jit.attach(errfin_handler, 'errfin') > +local status = pcall(test_f) > +-- We have to stop GC now because any step raises the error due to > +-- cursed cdata objects. > +collectgarbage('stop') > +test:ok(status, 'test function completed successfully') > +test:ok(error_in_finalizer, 'error handler called') > + > +test:done(true) > diff --git a/test/tarantool-tests/lj-946-print-errors-from-gc-fin-default.test.lua b/test/tarantool-tests/lj-946-print-errors-from-gc-fin-default.test.lua > new file mode 100644 > index 00000000..dfef11e5 > --- /dev/null > +++ b/test/tarantool-tests/lj-946-print-errors-from-gc-fin-default.test.lua > @@ -0,0 +1,11 @@ > +local tap = require('tap') > +local test = tap.test('lj-flush-on-trace'):skipcond({ > + ['Test requires JIT enabled'] = not jit.status(), > +}) > + > +test:plan(1) > + > +local script = require('utils').exec.makecmd(arg, { redirect = '2>&1' }) > +local output = script() > +test:like(output, '.*ERROR in finalizer:.*') Minor: '.*' aren't necessary here. I suppose, that regex 'ERROR in finalizer:' is much readable and has the same meaning. > +test:done(true) > diff --git a/test/tarantool-tests/lj-946-print-errors-from-gc-fin-default/script.lua b/test/tarantool-tests/lj-946-print-errors-from-gc-fin-default/script.lua > new file mode 100644 > index 00000000..fdd9ced1 > --- /dev/null > +++ b/test/tarantool-tests/lj-946-print-errors-from-gc-fin-default/script.lua > @@ -0,0 +1,24 @@ > +local ffi = require('ffi') > + > +local function new_bad_cdata() > + return ffi.gc(ffi.new('char [?]', 1024), 'uncallable string') > +end > + > +local function test_f() > + collectgarbage('collect') > + -- Make GC aggressive enough to end the atomic phase before > + -- exiting the trace. > + collectgarbage('setstepmul', 400) > + -- The number of iterations is empirical, just big enough for the Nit: comment line length is more than 66 symbols. > + -- issue to strike. > + for _ = 1, 4000 do > + new_bad_cdata() > + end > +end > + > +jit.opt.start('hotloop=1') > +local status = pcall(test_f) > +-- We have to stop GC now because any step raises the error due to > +-- cursed cdata objects. > +collectgarbage('stop') > +assert(status, 'error is not rethrown') > -- > 2.39.3 (Apple Git-145) > -- Best regards, Sergey Kaplun
next prev parent reply other threads:[~2023-11-08 8:25 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-07 21:06 [Tarantool-patches] [PATCH luajit v2 0/2] gc: handle errors in finalizers Maksim Kokryashkin via Tarantool-patches 2023-11-07 21:06 ` [Tarantool-patches] [PATCH luajit v2 1/2] Print errors from __gc finalizers instead of rethrowing them Maksim Kokryashkin via Tarantool-patches 2023-11-08 8:21 ` Sergey Kaplun via Tarantool-patches [this message] 2023-11-09 0:03 ` Maxim Kokryashkin via Tarantool-patches 2023-11-09 12:03 ` Sergey Bronnikov via Tarantool-patches 2023-11-09 12:14 ` Maxim Kokryashkin via Tarantool-patches 2023-11-09 13:14 ` Sergey Bronnikov via Tarantool-patches 2023-11-07 21:06 ` [Tarantool-patches] [PATCH luajit v2 2/2] Fix last commit Maksim Kokryashkin via Tarantool-patches 2023-11-08 8:37 ` Sergey Kaplun via Tarantool-patches 2023-11-09 0:04 ` Maxim Kokryashkin via Tarantool-patches 2023-11-09 12:08 ` Sergey Bronnikov via Tarantool-patches 2023-11-23 6:30 ` [Tarantool-patches] [PATCH luajit v2 0/2] gc: handle errors in finalizers Igor Munkin via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZUtE-Hy6hGePdHqI@root \ --to=tarantool-patches@dev.tarantool.org \ --cc=max.kokryashkin@gmail.com \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit v2 1/2] Print errors from __gc finalizers instead of rethrowing them.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox