Re: [PATCH 3/4] test: fix tst.depth.sh to use proper trigger
Eugene Loh <[email protected]>
| Newsgroups | dev.linux.lists.dtrace |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > --- > 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