From: Robert Elz <kre@munnari.OZ.AU>
To: Harald van Dijk <harald@gigawatt.nl>
Cc: Martijn Dekker <martijn@inlv.org>,
DASH shell mailing list <dash@vger.kernel.org>,
busybox <busybox@busybox.net>,
Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org>,
Jilles Tjoelker <jilles@stack.nl>
Subject: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Fri, 07 Feb 2020 03:43:40 +0700 [thread overview]
Message-ID: <15235.1581021820@jinx.noi.kre.to> (raw)
In-Reply-To: <f8b210f5-dd59-2c7f-05d4-be0a89316d3d@gigawatt.nl>
Date: Thu, 6 Feb 2020 19:29:41 +0000
From: Harald van Dijk <harald@gigawatt.nl>
Message-ID: <f8b210f5-dd59-2c7f-05d4-be0a89316d3d@gigawatt.nl>
| Nice test.
Yes!
| and the various ash-based shells do not unblock it.
We do now, the fix for that will be in 9.0 when it is released.
("now" as in as of the past half hour...)
| Because of that,
| they do not pick up on the fact that the child process has terminated.
It was actually a race condition, for me it 'worked' about half the time
(seems to depend whether the wait happens in the parent before or after
the sub-process exits).
kre
ps: that core dump was an "impossible to happen" condition that this
actually made happen, that will be fixed as well, both by actually now
making it impossible like it was supposed to be (by not blocking or
ignoring SIGCHLD, ever) and by testing for it happening anyway...
The secondary fix for that one is still to be committed after I investigate
some more - I know what happened, just need to make sure what will happen
now if this situation which should never occur ever does happen again.
That the 8.1 NetBSD sh seems to work is more just an artifact of how
it runs the race I believe (or guess) - the wait & process invocation code
has changed a lot in 9 (well, 9.0RC2 for now) which seems to have made the
race a close call, instead of one sided. But that was not an artifact of
the environment for the test, it happens for me on a real -8(ish) type
system as well.
kre
next prev parent reply other threads:[~2020-02-06 21:02 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 [this message]
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
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=15235.1581021820@jinx.noi.kre.to \
--to=kre@munnari.oz.au \
--cc=bug-bash@gnu.org \
--cc=busybox@busybox.net \
--cc=dash@vger.kernel.org \
--cc=harald@gigawatt.nl \
--cc=jilles@stack.nl \
--cc=martijn@inlv.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).