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][v2] Always close profiler output file.
Date: Wed, 26 Feb 2025 14:58:08 +0300 [thread overview]
Message-ID: <Z78B0BD8CeWNw0h2@root> (raw)
In-Reply-To: <93178b00-f3e0-4145-932f-bd273935a477@tarantool.org>
Hi, Sergey,
Thanks for the fixes!
See my answers below.
On 25.02.25, Sergey Bronnikov wrote:
> Hi, Sergey,
>
> thanks for review! Updates applied and force-pushed.
>
> Sergey
>
> On 13.02.2025 18:31, Sergey Kaplun via Tarantool-patches wrote:
> > Hi, Sergey!
> > Thanks for the fixes and clarification!
> > Please consider by answers below.
> >
> > On 12.02.25, Sergey Bronnikov wrote:
<snipped>
> >
> >> +local script = utils.exec.makecmd(arg)
> >> +-- Execute a Lua script with start and stop LuaJIT profiler,
> >> +-- it is expected no samples found by profiler. The script's
> >> +-- output is suppressed, it is not interested.
> >> +local _ = script(p_filename, p_postfix)
> >> # > I don't get it. Why do we need the separate script for it?
> >> # prof_finish() is executed first time on calling `jit.p.stop()`
> >> #
> >> # and executed second time when GC finalizer is calling [1] and therefore
> >> # message "'[No samples collected]'" appears
> >> #
> >> # two times in the output file.
> >> #
> >> # 1.https://github.com/tarantool/luajit/blob/80360fb2e570ce8d54ff59ccf0bcd5dfb6b98527/src/jit/p.lua#L290
> >> #
> >> # We can inline script.lua to a test body and call garbage collector manually,
> >> # but I propose to leave it as is because executing as a separate process is
> >> # more real use case.
> > Now it is clear to me, thanks!
> >
> > This is another face of the bug that was fixed by this commit.
> > Nice catch!
> >
> > In the original issue, automated parsing shows empty file content.
> > I suppose it was done with something like the following:
> >
> > | LUA_PATH="src/?.lua;;" src/luajit -e '
> > | local jp = require"jit.p"
> > | local filename = "/tmp/j.p"
> > |
> > | collectgarbage("stop")
> > | jp.start("i9999999", filename)
> > | jp.stop()
> > |
> > | local f = io.open(filename, "r")
> > | print(("<%s>"):format(f:read("*all")))
> > | f.close()
> > | collectgarbage("restart")
> > | os.remove(filename)
> > | '
> >
> > Before the patch, I get the following output:
> >
> > | <>
> >
> > After the patch, I get the following output:
> >
> > | <[No samples collected]
> > | >
> ok, replaced testcase
> +-- See also: https://github.com/LuaJIT/LuaJIT/issues/1304
Nit: Missed dot at the end of the sentence.
<snipped>
> +
> + jit_p.start('i9999999', filename)
Please add the comment before the call that we set the interval of the
profiling to a huge enough value to be sure that there are no samples
collected.
> + jit_p.stop()
> +
> + local f = io.open(filename, 'r')
> + local p_content = io.open(filename):read('a*')
> + test:is(p_content, '[No samples collected]\n', 'profile dump has no samples')
> + f.close()
Typo: s/f./f:/
> +
> + -- Teardown.
> + collectgarbage('restart')
> + os.remove(filename)
> >
> > I guess this is the use case for guys from the NeoVim:
> > They run the profiler inside the application but have no samples
> > collected. The inspector may read the file from the different process,
> > but there is no need for it. And, yes, in the test we have to manually
> > stop and restart the GC, but only for the stability of the reproducer.
> > It is not a part of a use case itself.
> >
> > Your test case may be simplified as the following (in terms of my
> > script):
> > | LUA_PATH="src/?.lua;;" src/luajit -e '
> > | local jp = require"jit.p"
> > | local filename = "/tmp/j.p"
> > |
> > | collectgarbage("stop")
> > | jp.start("i9999999", filename)
> > | jp.stop()
> > |
> > | -- Unload the module and clean the local.
> > | package.loaded["jit.p"] = nil
> > | jp = nil
> > | collectgarbage("collect")
> > |
> > | local f = io.open(filename, "r")
> > | print(("<%s>"):format(f:read("*all")))
> > | f.close()
> > | collectgarbage("restart")
> > | os.remove(filename)
> > | '
> > | <[No samples collected]
> > | [No samples collected]
> > | >
> >
> > Since, IMHO, there is no need to check the </proc/$$/fd> content (see
> > the rationale below), we may use this test case in the original file
> > without the helper script.
> >
> > So, let's check both cases (the original one and that found by you) in
> > the test.
>
> What is a rationale for this?
As I said before, this is an additional possible demonstration of the
bug. I see nothing bad to add it as well, since it simulates a little
bit different workload -- flushing the output before we finish the
process or if we unload the module. I am not insisting on it, though.
>
> This is a helper script for LuaJIT profiler and according to our
> backporting rules
>
> test must cover a backported patch. This rule is fulfilled by my test.
<snipped>
--
Best regards,
Sergey Kaplun
next prev parent reply other threads:[~2025-02-26 11:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 12:20 Sergey Bronnikov via Tarantool-patches
2025-02-13 15:31 ` Sergey Kaplun via Tarantool-patches
2025-02-25 8:58 ` Sergey Bronnikov via Tarantool-patches
2025-02-26 11:58 ` Sergey Kaplun via Tarantool-patches [this message]
2025-02-27 13:07 ` Sergey Bronnikov via Tarantool-patches
2025-03-04 15:40 ` Sergey Kaplun via Tarantool-patches
2025-03-05 14:13 ` Sergey Bronnikov via Tarantool-patches
2025-03-05 14:58 ` Sergey Kaplun via Tarantool-patches
2025-03-05 15:09 ` Sergey Bronnikov via Tarantool-patches
2025-03-12 11:12 ` Sergey Kaplun 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=Z78B0BD8CeWNw0h2@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][v2] Always close profiler output file.' \
/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