[DTrace-devel] [PATCH 3/4] test: fix tst.depth.sh to use proper trigger

Eugene Loh eugene.loh at oracle.com
Tue Nov 11 00:10:52 UTC 2025


I'm against this patch.

The picky stuff is:
- the Copyright year should be updated
- the timeout probe could replace
         tick-1sec /n++ == 10/
   with simply
         tick-10sec
- the "delay" env var be set for delaydie???
- the ustacks for delaydie are perhaps not very interesting

A little more serious is that all this patch does is swap one failure 
mode for another.  What for?  It's XFAIL anyhow, and we do not check 
that we're getting a particular, expected failure.

The real problem, meanwhile, is that this patch leads to lots of test 
failures, at least for me.  Not every VM, but many.  Oh, and I do not 
mean on this test, because this test remains XFAIL anyhow.

Consider a subset of the VMs I run on.  I get these failures on the 
test/unittest/ustack/tst.*.d tests.  Why on these?  Because they run 
after tst.depth.sh.

         +------------------  arm OL8  UEK7
         | +----------------  x86 OL9  UEK7
         | | +--------------  arm OL9  UEK7
         | | | +------------  x86 OL9  UEK8
         | | | | +----------  arm OL9  UEK8
         | | | | | +--------  arm OL10 UEK8
         | | | | | |
         v v v v v v

         x x x x x x   tst.kthread.d                 FAIL: timed out.
         x   x   x x   tst.uaddr.d                   FAIL: timed out.
         x   x   x x   tst.uaddr-pid0.d              FAIL: timed out.
                 x x   tst.ufunc.d                   FAIL: timed out.
             x   x x   tst.ufunc-pid0.d              FAIL: timed out.
                 x x   tst.umod.d                    FAIL: timed out.
                 x x   tst.ustack25_max95_profile.d  FAIL: timed out.
                 x x   tst.ustack25_pid.d            FAIL: timed out.
                 x x   tst.ustack25_profile.d        FAIL: timed out.
                 x x   tst.ustack95_max25_profile.d  FAIL: timed out.
                 x x   tst.ustack95_profile.d        FAIL: timed out.
                 x x   tst.ustack_max25_profile.d    FAIL: timed out.
                 x x   tst.ustack_profile.d          FAIL: timed out.
                 x     tst.usym.d                    FAIL: timed out.
                 x     tst.usym-pid0.d               FAIL: timed out.

I think the problem is that tst.depth.sh -- with this patch, in any case 
-- turns on a huge number of probes.  That causes problems for this 
test, but not in the sense of it FAILing since it is marked XFAIL 
anyhow.  (All this patch does is change the FAIL from one problem to 
another, but we still do not specify what failure we expect to see nor 
check that that is what we get.)

So, the problem is not with this test, but that the system is left in 
some whacked state due to having attempted so many probes.  As a result, 
the process "dtrace -o $file -c delaydie" is still around well after the 
depth test has finished, the load average remains high, the pid0 process 
does not run, and many tests time out.  How long (how many seconds or 
how many tests) does this effect last?  It depends, as one can see above.

This raises all sorts of other questions as well, such as whether tests 
in our test suite should be allowed to depend on running on a somewhat 
idle system, whether we (dtrace or the test suite) are cleaning up well 
enough, etc.

On 11/10/25 10:27, Kris Van Hees wrote:
> The test used 'date' as its trigger but that caused the test to XFAIL
> for the wrong reason: date does not have symbols and therefore dtrace
> failed to enable probes for it.
>
> Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
> ---
>   test/unittest/ustack/tst.depth.sh | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/test/unittest/ustack/tst.depth.sh b/test/unittest/ustack/tst.depth.sh
> index dec16a3a..977d1b42 100755
> --- a/test/unittest/ustack/tst.depth.sh
> +++ b/test/unittest/ustack/tst.depth.sh
> @@ -16,7 +16,7 @@ dtrace=$1
>   
>   rm -f $file
>   
> -$dtrace $dt_flags -o $file -c date -s /dev/stdin <<EOF
> +$dtrace $dt_flags -o $file -c test/triggers/delaydie -s /dev/stdin <<EOF
>   
>   	#pragma D option quiet
>   	#pragma D option bufsize=1M
> @@ -45,7 +45,7 @@ $dtrace $dt_flags -o $file -c date -s /dev/stdin <<EOF
>   EOF
>   
>   status=$?
> -if [ "$status" -ne 0 ]; then
> +if [ $status -ne 0 ]; then
>   	echo $tst: dtrace failed
>   	rm -f $file
>   	exit $status
> @@ -78,8 +78,8 @@ EOF
>   
>   status=$?
>   
> -count=`wc -l $file | cut -f1 -do`
> -if [ "$count" -lt 1000 ]; then
> +count=`wc -l $file | cut -f1 -d' '`
> +if [ $count -lt 1000 ]; then
>   	echo $tst: output was too short
>   	status=1
>   fi



More information about the DTrace-devel mailing list