From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Sergey Bronnikov <sergeyb@tarantool.org> Cc: Sergey Bronnikov <estetus@gmail.com>, tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit 4/7][v2] sysprof: introduce specific errors and default mode Date: Wed, 19 Feb 2025 18:20:10 +0300 [thread overview] Message-ID: <Z7X2qlvxLu80j-18@root> (raw) In-Reply-To: <ec473c29-fa1d-4e56-a4ea-0d2e2d2546f4@tarantool.org> Hi, Sergey! Thanks for the fixes! Adds some comments related to our offline discussion below. On 19.02.25, Sergey Bronnikov wrote: > Hi, Sergey, > > thanks for review! > > On 18.02.2025 18:43, Sergey Kaplun via Tarantool-patches wrote: > > Hi, Sergey! > > Thanks for the fixes! > > After refactoring the code become more readable, thanks! > > Now I have a few ideas, see my comments below. > > > > On 13.02.25, Sergey Bronnikov wrote: > >> sysprof has a number of options and with any incorrect option it > >> returns `false` and error message "profiler misuse". This message > >> discourage sysprof users and make using sysprof more complicated. > > Typo: s/discourage/discourages/ > > Typo: s/make/makes/ > Fixed. > > > >> The patch sets default profiling mode ("D", that shows only > > Typo: s/default/the default/ > Fixed. > > > >> virtual machine state counters) if it was not passed and adds > >> details to the error message with possible reasons of misuse. > >> --- > >> src/lib_misc.c | 80 +++++++++++++------ > >> src/lj_errmsg.h | 5 ++ > >> .../profilers/misclib-sysprof-lapi.test.lua | 48 +++++++++-- > >> 3 files changed, 100 insertions(+), 33 deletions(-) > >> > >> diff --git a/src/lib_misc.c b/src/lib_misc.c > >> index 5b7a4b62..d71904e4 100644 > >> --- a/src/lib_misc.c > >> +++ b/src/lib_misc.c > >> @@ -163,6 +163,7 @@ static int on_stop_cb_default(void *opt, uint8_t *buf) > >> > >> /* The default profiling interval equals to 10 ms. */ > >> #define SYSPROF_DEFAULT_INTERVAL 10 > >> +#define SYSPROF_DEFAULT_MODE "D" > >> #define SYSPROF_DEFAULT_OUTPUT "sysprof.bin" > >> > >> static int set_output_path(const char *path, struct luam_Sysprof_Options *opt) { > >> @@ -177,21 +178,41 @@ static int set_output_path(const char *path, struct luam_Sysprof_Options *opt) { > >> return PROFILE_SUCCESS; > >> } > >> > >> -static int parse_sysprof_opts(lua_State *L, struct luam_Sysprof_Options *opt, int idx) { > >> - GCtab *options = lj_lib_checktab(L, idx); > >> +static int parse_sysprof_opts(lua_State *L, struct luam_Sysprof_Options *opt, > >> + const char **err_details) { > >> + int n = (int)(L->top - L->base); > >> + if (n != 1) { > > I suppose this should be `n == 0`. Otherwise we will observe the > > following behaviour: > > | src/luajit -e 'print(misc.sysprof.start(1, 2, 3))' > > | true > Right, fixed. > >> + opt->mode = LUAM_SYSPROF_DEFAULT; > >> + opt->interval = SYSPROF_DEFAULT_INTERVAL; > >> + goto set_path; > > I suppose it is better to set path explicitly here and goto ctx_allocate; > > The code that make a jump to the middle of basic block smells bad. > > It makes control flow more complicated, and benefits are not obvious. I suppose we may just return here since we don't get into the if condition under the label below. > > > > >> + } > >> + > >> + if (!lua_istable(L, 1)) { > > The more I think about it, the more it looks like a bug -- all library > > functions raise an error when they get a bad parameter type. > > > > Maybe we should just use `lj_lib_checktab()` here? This will help the > > user to find an error and be consistent with memprof behaviour. So, > > bugfix isn't breaking change, since something is working incorrectly. > > Plus, as a bonus we don't need to introduce the new error with the same > > meaning we have already. > > > > OTOH, if you are against it, we may leave it as is, but check it via > > `tvistab()` instead. > > > > What do you think? > > > > And the same should be done with the parameters in table content -- > > their type should be checked at once and the corresponding error should > > be raised. I suppose we can introduce a local (inside this translation > > unit) helper `key_opt_type()` here -- we will check a type for the keys > > `path`, `mode`, `interval` and raise the user-friendly error like: > > What for? The reason of this patch series is bad error handling in > profilers. > > The value behind this refactoring is not obvious. Please elaborate. > > This code was imperfect for about 2-3 years and this was ok for everyone > > who added it initially. I don't want to fix all bad places here, just > improve error messages visible by end users. Discussed offline only to fix the bug with `lua_istable()` vs `lj_lib_checktab()`. The options validation is OK it is the current state. > > > > > `bad key 'mode' in 'start' argument (string expected, got table)`. > > See how it is done in `lj_lib_check*()` for inspiration. > > > >> + *err_details = err2msg(LJ_ERR_PROF_DETAILS_BADTABLE); > >> + return PROFILE_ERRUSE; > >> + } > >> + > >> + GCtab *options = lj_lib_checktab(L, 1); > > This check is excess, let's move it above, as I suggested. > > it is not a check, it's a function that retrieves a table from the stack. See the comment above. <snipped> > >> +set_path: > >> + > >> /* Get output path. */ > >> if (opt->mode != LUAM_SYSPROF_DEFAULT) > >> { > >> @@ -230,8 +256,10 @@ static int parse_sysprof_opts(lua_State *L, struct luam_Sysprof_Options *opt, in > >> cTValue *pathtv = lj_tab_getstr(options, lj_str_newlit(L, "path")); > >> if (!pathtv) > >> path = SYSPROF_DEFAULT_OUTPUT; > >> - else if (!tvisstr(pathtv)) > >> + else if (!tvisstr(pathtv)) { > > It is better to wrap if and else branches too like the following: > > | if () { > > | } else if () { > > | } else { > > | } > > It's funny, on the previous review brackets were excess [1]. > > 1. https://lists.tarantool.org/tarantool-patches/Z6XlUsKqu92__8fL@root/T/#t This was about single if usage not `if-else if-else` statements. > > Brackets are not needed in the first and third blocks, if we're > following a rule "brackets for blocks with more than one statements". > > > >> + *err_details = err2msg(LJ_ERR_PROF_DETAILS_BADPATH); > >> return PROFILE_ERRUSE; > >> + } > >> else > >> path = strVdata(pathtv); > >> > >> @@ -251,29 +279,28 @@ static int parse_sysprof_opts(lua_State *L, struct luam_Sysprof_Options *opt, in > >> return PROFILE_SUCCESS; > >> } > >> > >> -static int parse_options(lua_State *L, struct luam_Sysprof_Options *opt) > >> -{ > >> - if (lua_gettop(L) != 1) > >> - return PROFILE_ERRUSE; > >> - > >> - if (!lua_istable(L, 1)) > >> - return PROFILE_ERRUSE; > >> - > >> - return parse_sysprof_opts(L, opt, 1); > >> -} > >> - > >> -static int sysprof_error(lua_State *L, int status) > >> +static int sysprof_error(lua_State *L, int status, const char *err_details) > >> { > >> switch (status) { > >> case PROFILE_ERRUSE: > >> lua_pushnil(L); > >> lua_pushstring(L, err2msg(LJ_ERR_PROF_MISUSE)); > >> + if (err_details) { > >> + lua_pushstring(L, ": "); > > I suppose we may use string formatting here instead of concatenation Lua > > C API call: > > See usage of `lj_strfmt_pushf()` for the details. > > Sure, we may, but what for? > > Previous functions are a part of Lua C API (lua_pushnil, lua_pushstring), > > why do we need to mix Lua C functions with this LJ-specific function? We don't bother the Lua stack with excess pushes and additional concatenation, if we know exactly how many values on the stack we need. <snipped> > >> diff --git a/src/lj_errmsg.h b/src/lj_errmsg.h > >> index 19c41f0b..b5c3a275 100644 > >> --- a/src/lj_errmsg.h > >> +++ b/src/lj_errmsg.h > >> @@ -188,6 +188,11 @@ ERRDEF(PROF_ISRUNNING, "profiler is running already") > >> ERRDEF(PROF_NOTRUNNING, "profiler is not running") > >> #endif > >> > >> +ERRDEF(PROF_DETAILS_BADMODE, "profiler 'mode' must be 'D', 'L' or 'C'") > >> +ERRDEF(PROF_DETAILS_BADINTERVAL, "profiler 'interval' must be greater than 1") > >> +ERRDEF(PROF_DETAILS_BADPATH, "profiler path does not exist") This should be something like the following: | "profiler 'path' should be a string" > >> +ERRDEF(PROF_DETAILS_BADTABLE, "profiler expects a table with parameters") > >> + > > These changes should be under the LJ_HASSYSPROF ifdef. > > Also, I suggest the following naming: > > | SYSPROF_BADMODE > > | SYSPROF_BADINTERVAL > > With this it will be obviour that they are sysprof-specific and not too > > long. > > Imagine you then introduce a table and interval number for memprof. > > Will you rename constants back? I dislike your suggestion. OK, let's leave it as is. > > > > >> #undef ERRDEF > >> > >> /* Detecting unused error messages: > >> diff --git a/test/tarantool-tests/profilers/misclib-sysprof-lapi.test.lua b/test/tarantool-tests/profilers/misclib-sysprof-lapi.test.lua > >> index 32fa384c..7622323a 100644 > >> --- a/test/tarantool-tests/profilers/misclib-sysprof-lapi.test.lua > >> +++ b/test/tarantool-tests/profilers/misclib-sysprof-lapi.test.lua > >> @@ -10,7 +10,7 @@ local test = tap.test("misclib-sysprof-lapi"):skipcond({ > >> ["Disabled due to #10803"] = os.getenv("LUAJIT_TEST_USE_VALGRIND"), > >> }) > >> > >> -test:plan(19) > >> +test:plan(33) > >> > >> jit.off() > >> -- XXX: Run JIT tuning functions in a safe frame to avoid errors > >> @@ -65,10 +65,25 @@ end > >> > >> -- Wrong profiling mode. > >> local res, err, errno = misc.sysprof.start{ mode = "A" } > >> -test:ok(res == nil anderr:match("profiler misuse"), > >> - "result status with wrong profiling mode") > >> +test:ok(res == nil, "result status with wrong profiling mode") > >> +test:ok(err:match("profiler mode must be 'D', 'L' or 'C'"), > >> + "error with wrong profiling mode") > > I would rather still check matching with `profiler misuse:` error (as a > > separate testcase). Here and below. But it's up to you. Feel free to > > ignore. > I think that checking specific part of error message is enough. Ok. <snipped> > >> @@ -92,11 +107,30 @@test:ok(res == nil anderr:match("No such file or directory"), > >> "result status and error with bad path") > >> test:ok(type(errno) == "number", "errno with bad path") > >> > >> --- Bad interval. > >> +-- Bad interval (-1). > >> res, err, errno = misc.sysprof.start{ mode = "C", interval = -1 } > >> -test:ok(res == nil anderr:match("profiler misuse"), > >> - "result status and error with bad interval") > >> -test:ok(type(errno) == "number", "errno with bad interval") > >> +test:is(res, nil, "result status and error with bad interval -1") > >> +test:ok(err:match("profiler interval must be greater than 1"), > >> + "error with bad interval -1") > >> +test:ok(type(errno) == "number", "errno with bad interval -1") > >> + > >> +-- Bad interval (0). > >> +res, err, errno = misc.sysprof.start{ mode = "C", interval = 0 } > >> +test:ok(res == nil, "res with bad interval 0") > >> +test:ok(err:match("profiler interval must be greater than 1"), > >> + "error with bad interval 0") > >> +test:ok(type(errno) == "number", "errno with bad interval 0") > >> + > >> +-- Good interval (1). > >> +res, err, errno = misc.sysprof.start{ > > Minor: Please use brackets for functions call. > > Case without brackets is more popular: <snipped> > proposed change will make coding style inconsistent in the file OK, my bad. > > > <snipped> > >> -- > >> 2.34.1 > >> -- Best regards, Sergey Kaplun
next prev parent reply other threads:[~2025-02-19 15:20 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-13 11:10 [Tarantool-patches] [PATCH luajit 0/7][v2] Fix profilers issues Sergey Bronnikov via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 1/7][v2] test: add descriptions to sysprof testcases Sergey Bronnikov via Tarantool-patches 2025-02-18 11:04 ` Sergey Kaplun via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 2/7] sysprof: align test title with test filename Sergey Bronnikov via Tarantool-patches 2025-02-18 11:10 ` Sergey Kaplun via Tarantool-patches 2025-02-18 14:02 ` Sergey Bronnikov via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 3/7][v2] sysprof: fix typo in the comment Sergey Bronnikov via Tarantool-patches 2025-02-18 11:10 ` Sergey Kaplun via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 4/7][v2] sysprof: introduce specific errors and default mode Sergey Bronnikov via Tarantool-patches 2025-02-18 15:43 ` Sergey Kaplun via Tarantool-patches 2025-02-19 9:34 ` Sergey Bronnikov via Tarantool-patches 2025-02-19 15:20 ` Sergey Kaplun via Tarantool-patches [this message] 2025-02-19 16:08 ` Sergey Bronnikov via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 5/7] ci: add workflow with disabled profilers Sergey Bronnikov via Tarantool-patches 2025-02-18 12:10 ` Sergey Kaplun via Tarantool-patches 2025-02-18 14:14 ` Sergey Bronnikov via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 6/7] misc: specific message for " Sergey Bronnikov via Tarantool-patches 2025-02-19 8:06 ` Sergey Kaplun via Tarantool-patches 2025-02-19 12:53 ` Sergey Bronnikov via Tarantool-patches 2025-02-19 15:41 ` Sergey Kaplun via Tarantool-patches 2025-02-19 15:56 ` Sergey Bronnikov via Tarantool-patches 2025-02-13 11:10 ` [Tarantool-patches] [PATCH luajit 7/7] memprof: set default path to profiling output file Sergey Bronnikov via Tarantool-patches 2025-02-18 11:55 ` Sergey Kaplun via Tarantool-patches 2025-02-18 14:20 ` Sergey Bronnikov 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=Z7X2qlvxLu80j-18@root \ --to=tarantool-patches@dev.tarantool.org \ --cc=estetus@gmail.com \ --cc=sergeyb@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit 4/7][v2] sysprof: introduce specific errors and default mode' \ /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