From: Kris Van Hees <kris.van.hees@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH v2] test: Wait for output to flush out in enable_pid
Date: Wed, 30 Jul 2025 10:18:17 -0400 [thread overview]
Message-ID: <aIopqYJP3yn8DzUf@oracle.com> (raw)
In-Reply-To: <20250628223050.3396-1-eugene.loh@oracle.com>
I still see intermittent FAILs. I wonder whether there is a potentially unsafe
contruct at work (see below).
On Sat, Jun 28, 2025 at 06:30:50PM -0400, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Our luck with this test has been quite good, but it sometimes fails
> to show its last lines of output. That is, we send a USR1 to the
> trigger processes to set off the final output and we immediately
> cat the output files. If there is any delay in handling the signal,
> the last output will be missing.
>
> Have the processes terminate themselves when their last output is
> flushed; then wait for those processes. Also, skip testing altogether if
> there is only a single processor to run the two, hard-spinning processes.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> test/unittest/usdt/tst.enable_pid.sh | 17 ++++++++++++-----
> test/unittest/usdt/tst.enable_pid.x | 8 ++++++++
> 2 files changed, 20 insertions(+), 5 deletions(-)
> create mode 100755 test/unittest/usdt/tst.enable_pid.x
>
> diff --git a/test/unittest/usdt/tst.enable_pid.sh b/test/unittest/usdt/tst.enable_pid.sh
> index 7f4f68698..296cfb382 100755
> --- a/test/unittest/usdt/tst.enable_pid.sh
> +++ b/test/unittest/usdt/tst.enable_pid.sh
> @@ -33,6 +33,8 @@ EOF
> cat > main.c <<EOF
> #include <signal.h>
> #include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> #include "prov.h"
>
> /* We check if the is-enabled probe is or is not enabled (or unknown). */
> @@ -41,7 +43,7 @@ cat > main.c <<EOF
> #define ENABLED_UNK 3
>
> /* Start with the previous probe "unknown". */
> -int prv = ENABLED_UNK;
> +int prv = ENABLED_UNK, nepochs_left = 4;
> long long num = 0;
>
> /* Report how many times the previous case was encountered. */
> @@ -71,6 +73,9 @@ static void mark_epoch(int sig) {
> report();
> printf("=== epoch ===\n");
> fflush(stdout);
> + nepochs_left--;
> + if (nepochs_left <= 0)
> + exit(0);
I wonder whether this could still cause some output to get lost. I would
actually move the conditional and exit to the end of the loop in main(),
so that we check nepochs_left and exit when <= 0 outside of the interrupt
handler.
I am running a long sequence of this test to see if that helps/fixes it.
> }
>
> int
> @@ -79,7 +84,7 @@ main(int argc, char **argv)
> struct sigaction act;
>
> /* Set USR1 to mark epochs. */
> - act.sa_flags = 0;
> + memset(&act, 0, sizeof(act));
> act.sa_handler = mark_epoch;
> if (sigaction(SIGUSR1, &act, NULL)) {
> printf("set handler failed\n");
> @@ -172,13 +177,15 @@ for pid in 1 $pid1 $pid2 '*'; do
> kill -USR1 $pid2
> done
>
> +# Wait for the processes.
> +wait $pid1
> +wait $pid2
> +
> +# Dump the output.
> echo done
> echo "========== out 1"; cat out.1
> echo "========== out 2"; cat out.2
>
> echo success
>
> -kill -TERM $pid1
> -kill -TERM $pid2
> -
> exit 0
> diff --git a/test/unittest/usdt/tst.enable_pid.x b/test/unittest/usdt/tst.enable_pid.x
> new file mode 100755
> index 000000000..9506674ee
> --- /dev/null
> +++ b/test/unittest/usdt/tst.enable_pid.x
> @@ -0,0 +1,8 @@
> +#!/bin/sh
> +
> +if [ `grep -c ^processor /proc/cpuinfo` -lt 2 ]; then
> + echo test should have at least two processors
> + exit 2
> +fi
> +
> +exit 0
> --
> 2.43.5
>
next prev parent reply other threads:[~2025-07-30 14:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-28 22:30 [PATCH v2] test: Wait for output to flush out in enable_pid eugene.loh
2025-07-22 13:38 ` Nick Alcock
2025-07-29 14:13 ` [DTrace-devel] " Kris Van Hees
2025-07-29 15:19 ` Kris Van Hees
2025-07-30 14:18 ` Kris Van Hees [this message]
2025-07-30 14:26 ` Kris Van Hees
2025-07-30 22:03 ` Eugene Loh
2025-07-30 22:39 ` Kris Van Hees
2025-07-31 0:17 ` Kris Van Hees
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=aIopqYJP3yn8DzUf@oracle.com \
--to=kris.van.hees@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.