Tarantool development patches archive
 help / color / mirror / Atom feed
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

  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