All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Robert Elz <kre@munnari.oz.au>, Martijn Dekker <martijn@inlv.org>,
	busybox <busybox@busybox.net>,
	DASH shell mailing list <dash@vger.kernel.org>,
	Jilles Tjoelker <jilles@stack.nl>,
	Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org>
Subject: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Tue, 18 Feb 2020 21:59:37 +0000	[thread overview]
Message-ID: <f2a928d6-4feb-d123-23b4-17c8edfeda2f@gigawatt.nl> (raw)
In-Reply-To: <CAK1hOcO_S_T=5SWJ0jpZWxDYwdUFqJisw_nC+JysnQvZ6XUuKw@mail.gmail.com>

On 18/02/2020 16:46, Denys Vlasenko wrote:
> On Sat, Feb 8, 2020 at 7:41 PM Harald van Dijk <harald@gigawatt.nl> wrote:
>> If NetBSD sh
>> manages to avoid this pattern, and assuming NetBSD sh is not still
>> susceptible to one of those race conditions
> 
> Please let us know what you discovered.

Okay, please take a look. I hope I managed to avoid race conditions in 
the test shell script.

test1.sh:

   i=1
   while test "$i" -lt 100000
   do
     printf "%d\r" "$i"
     "$@" test2.sh
     i=$((i + 1))
   done

test2.sh

   trap 'kill $!; exit 0' TERM
   { kill $$; exec sleep 1000; } &
   wait $!

To run:

   sh test1.sh $shell

For instance:

   sh test1.sh busybox ash

test1.sh will repeatedly run test2.sh and increment and print a counter 
variable to display progress.

test2.sh will immediately exit, in a complicated way, if all goes well. 
It may sleep for 1000s or fail to clean up its background process if 
something goes wrong.

On my system, I see:

   bash 5.0.11        - sleeps after a while
   bosh 2019-11-11    - sleeps after a while
   busybox 1.31.1 ash - ok
   dash 0.5.10.2      - ok
   dash (current)     - sleeps immediately
   fbsh 12.1          - ok *
   gwsh (current)     - leaves subprocesses
   ksh 93v            - sleeps after a while
   ksh 2020.0.0       - sleeps after a while
   mksh 57            - sleeps after a while
   nbsh (current)     - sleeps after a while *
   pdksh 5.2.14       - leaves subprocesses + sleeps after a while
   posh 0.13.1        - ok
   yash               - ok
   zsh                - sleeps after a while

* Because of the way I was running FreeBSD sh and NetBSD sh on qemu, I 
could not easily check what happens to the subprocesses.

I think that confirms that NetBSD sh does have a problem with a race 
condition, but that many shells have that same problem. It also tells me 
that there is another different problem in my shell that I should look at.

Cheers,
Harald van Dijk

  reply	other threads:[~2020-02-18 22:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 16:12 Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait' Martijn Dekker
2020-02-06 19:29 ` Harald van Dijk
2020-02-07 11:19   ` AW: " Walter Harms
2020-02-07 14:33     ` Martijn Dekker
2020-02-07 16:16   ` Chet Ramey
2020-02-06 20:43 ` Robert Elz
2020-02-07  2:41 ` Robert Elz
2020-02-08 18:39   ` Harald van Dijk
2020-02-09 19:03     ` Jilles Tjoelker
2020-02-18 16:46     ` Denys Vlasenko
2020-02-18 21:59       ` Harald van Dijk [this message]
2020-02-18 18:17     ` Robert Elz

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=f2a928d6-4feb-d123-23b4-17c8edfeda2f@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=bug-bash@gnu.org \
    --cc=busybox@busybox.net \
    --cc=dash@vger.kernel.org \
    --cc=jilles@stack.nl \
    --cc=kre@munnari.oz.au \
    --cc=martijn@inlv.org \
    --cc=vda.linux@googlemail.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.