From: Robert Elz <kre@munnari.OZ.AU>
To: Denys Vlasenko <email@example.com>
Cc: Jilles Tjoelker <firstname.lastname@example.org>, busybox <email@example.com>,
DASH shell mailing list <firstname.lastname@example.org>,
Harald van Dijk <email@example.com>,
Bug reports for the GNU Bourne Again SHell <firstname.lastname@example.org>,
Martijn Dekker <email@example.com>
Subject: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Wed, 19 Feb 2020 01:17:02 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Date: Tue, 18 Feb 2020 17:46:23 +0100
From: Denys Vlasenko <email@example.com>
| > 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.
It is very likley that it is racy as described, though no-one has ever
filed a bug report on it (ie: it hasn't happened to anyone in a way that
they'd complain about it).
I suspect it also isn't a conformance problem - POSIX says very
little about when traps are executed ... really only that they don't
interrupt waiting for a foreground command to complete, and that if a
trap occurs while waiting in the wait command, then that command ends
with an exit status indicating the signal.
What that means is that using traps for anything much more than cleanup
activities isn't really safe (or perhaps, s/safe/sane/) as there's no
guarantee when the trap will actually run.
Given that, losing the race in the situation cited (ie: getting the
signal just before running the waitpid() (or whichever) sys call when
implementing the wait command - and then going ahead and doing the
sys call, hanging until some process terminates (perhaps until a particular
process terminates) seems fully conformant to me (the signal doesn't
arrive while waiting, so no error return from wait is required).
It isn't nice, and ideally wouldn't happen (and in real life, seems
not to ... the window is quite small after all) but nothing should really
break badly because of it - or at least nothing portable should.
We do now unilaterally reset SIGCHLD to SIG_DFL/unblocked at startup
(SIGCHLD is the one signal we're not required to pass on to exec'd
processes in the same state we received it, so that's OK) so we could
adopt the block, catch SIGCHLD, and sigsuspend() approach if that ever
seemed like a necessary thing to do.
ps: the observed core dump problem is also fixed, that was a related,
but quite different, issue - not connected to SIGCHLD in any way at all.
prev parent reply other threads:[~2020-02-18 18:17 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
2020-02-18 18:17 ` Robert Elz [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).