public inbox for
 help / color / mirror / Atom feed
From: "rgoldber at redhat dot com" <>
Subject: [Bug translator/29801] New: --monitor mode gets 2 hits to procfs("monitor_control").write for every 1 write
Date: Thu, 17 Nov 2022 19:19:56 +0000	[thread overview]
Message-ID: <> (raw)

            Bug ID: 29801
           Summary: --monitor mode gets 2 hits to
                    procfs("monitor_control").write for every 1 write
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: rgoldber at redhat dot com
  Target Milestone: ---

When running monitor mode it looks like for every one write_command call there
are 2 hits to the procfs("monitor_control").write probe. This isn't really an
issue for things like resume and pause, but it causing an issue with quit,
causing the module to lockup

So it turns out that elaborate.cxx::monitor_mode_write derives the procfs write
probe and has it join(and init) the procfs_derived_probe_group. Which enrolls
the probe (adding it to the write_probes set)

Then in semantic_pass_optimize1 the probe is added to the group (and enrolled)
again which causes the second copy of the probe to be added to write_probes
(leading to the above issue)

So to fix this I can either just remove the join_group in monitor_mode_write
(or add some join_group internal conditional to avoid repeats) or I could do a
non-null check on groups before joining them in semantic_pass_optimize1 (but
this could result in new issues with probes which may rely on this underlying
behavior but also would lead to the widest covering solution)

Is their a preference for which fix I go with?

You are receiving this mail because:
You are the assignee for the bug.

             reply	other threads:[~2022-11-17 19:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17 19:19 rgoldber at redhat dot com [this message]
2022-11-17 19:38 ` [Bug translator/29801] " fche at redhat dot com
2022-11-18 15:58 ` rgoldber at redhat dot com

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).