public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] test: Skip err.Z_no-w for now
Date: Tue, 08 Jul 2025 13:15:08 +0100	[thread overview]
Message-ID: <87ldoyev5f.fsf@esperi.org.uk> (raw)
In-Reply-To: <20250708045257.13808-1-eugene.loh@oracle.com> (eugene loh's message of "Tue, 8 Jul 2025 00:52:57 -0400")

From: Eugene Loh <eugene.loh@oracle.com>
>
> It is unclear what behavior is desired.  For example, consider:
>
>      dtrace -Z -n 'BEGIN { exit(0) } foo:bar:baz:bop { raise(SIGUSR1) }'

... isn't the lack of semicolons here a syntax error? (Or have I been
inserting them pointlessly all these years just because awk needs them?)

>
> The first probe exists.  The second one will be ignored.  Solaris will
> reject the script with:
>
>      dtrace: description 'BEGIN ' matched 1 probe
>      dtrace: could not enable tracing: Destructive actions not allowed
>
> On Linux, we have:
>
>      dtrace: description 'BEGIN ' matched 1 probe
>      CPU     ID                    FUNCTION:NAME
>        0      1                           :BEGIN
>
> Perhaps both behaviors have merit.  For now, just skip the test to
> avoid test failures we are not ready to arbitrate.

Does execution fail if the probe exists but there's a BEGIN that exits?
I guess so. So the interesting question is: if you start with -Z and
specify a destructive action in a nonexistent probe, and then a
USDT-containing program starts up that provides that probe, what do we
do? If we don't terminate, that would be surprising. If we terminate in
the middle of execution, would that be more surprising than checking all
bodies at startup and failing early?

-- 
NULL && (void)

  reply	other threads:[~2025-07-08 12:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08  4:52 [PATCH] test: Skip err.Z_no-w for now eugene.loh
2025-07-08 12:15 ` Nick Alcock [this message]
2025-07-09 22:39   ` Eugene Loh
2025-07-09 23:45     ` Kris Van Hees
2025-07-10 20:03       ` Eugene Loh
2025-07-10 20:12         ` Kris Van Hees
2025-07-11  4:37           ` Eugene Loh

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=87ldoyev5f.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /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
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