[DTrace-devel] [PATCH] test: Skip err.Z_no-w for now

Eugene Loh eugene.loh at oracle.com
Wed Jul 9 22:39:31 UTC 2025


On 7/8/25 08:15, Nick Alcock wrote:

> From: Eugene Loh <eugene.loh at 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?)

I routinely omit semicolons.  Okay since even Solaris.  E.g.,

# uname -s
SunOS
# /usr/sbin/dtrace -n 'BEGIN { printf("hello") } BEGIN { printf("world") 
} BEGIN { exit(0) }'
dtrace: description 'BEGIN ' matched 3 probes
  CPU     ID                    FUNCTION:NAME
   51      1                           :BEGIN hello
   51      1                           :BEGIN world
   51      1                           :BEGIN

>> 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.

Right.

> 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?

I think I finally understand what's going on.  The point of this patch 
was to move on to more urgent matters, but there is maybe a bug here I 
should fix.

Solaris rejects a clause even if it's not going to be used.  E.g.,

     # dtrace -Z -n 'BEGIN { exit(0) }
         bogus:bogus:bogus:bogus { raise(SIGUSR1) }'

Solaris says:

     dtrace: description 'BEGIN ' matched 1 probe
     dtrace: could not enable tracing: Destructive actions not allowed

Nevermind we do not use the second probe description.  It's a baddie.  
Our Linux port has no such complaint.

What about the case you propose (which is, after all, the question being 
addressed by this test)?  Well, "it depends."  Put another way, we won't 
run a destructive clause without -w.  The problem is that during 
discovery, we might first encounter an is-enabled probe (which we 
"enable" since it's safe), then later encounter a real probe and reject 
it due to its destructive clause.  If you squint just right, you could 
see this as being not incorrect, but it's kind of goofy.

Ideally, enabling probes and their is-enabled probes atomically would be 
the right thing to do.  That's a tall order.

But falling back to the Solaris behavior of rejecting destructive 
clauses without -w is the right thing to do, even if we are not using 
them (yet).



More information about the DTrace-devel mailing list