[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