dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Walter Harms <wharms@bfs.de>
To: Harald van Dijk <harald@gigawatt.nl>,
	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>,
	Robert Elz <kre@munnari.OZ.AU>, Jilles Tjoelker <jilles@stack.nl>
Subject: AW: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Fri, 7 Feb 2020 11:19:28 +0000	[thread overview]
Message-ID: <cbe5644f6db94eb89e4088141c426f8a@bfs.de> (raw)
In-Reply-To: <f8b210f5-dd59-2c7f-05d4-be0a89316d3d@gigawatt.nl>

IMHO is the bug on bash side. ash can assume to get an "healthy" environment from the caller. You can simply not fix everything that can possible go wrong.

Obviously it should not segfault but so far i understand it is bsd as that does, not busybox ash.

Von: busybox <busybox-bounces@busybox.net> im Auftrag von Harald van Dijk <harald@gigawatt.nl>
Gesendet: Donnerstag, 6. Februar 2020 20:29
An: Martijn Dekker; DASH shell mailing list; busybox; Bug reports for the GNU Bourne Again SHell; Robert Elz; Jilles Tjoelker
Betreff: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'

On 06/02/2020 16:12, Martijn Dekker wrote:
> This is probably the strangest bug (or maybe pair of bugs) I've run into
> in nearly five years of breaking shells by developing modernish.
> I've traced it to an interaction between bash >= 4.2 (i.e.: bash with
> shopt -s lastpipe) and variants of the Almquist shell, at least: dash,
> gwsh, Busybox ash, FreeBSD sh, and NetBSD 9.0rc2 sh.
> Symptom: if 'return' is invoked on bash in the last element of a pipe
> executed in the main shell environment, then if you subsequently 'exec'
> an Almquist shell variant so that it has the same PID, its 'wait'
> builtin breaks.
> I can consistently reproduce this on Linux, macOS, FreeBSD, NetBSD
> 9.0rc2, OpenBSD, and Solaris.
> To reproduce this, you need bash >= 4.2, some Almquist shell variant,
> and these two test scripts:
> ---begin test.bash---
> fn() {
>      : | return
> }
> shopt -s lastpipe || exit
> fn
> exec "${1:-dash}" test.ash
> ---end test.bash---
> ---begin test.ash---
> echo '*ash-begin'
> : &
> echo '*ash-middle'
> wait "$!"
> echo '*ash-end'
> ---end test.ash---
> When executing test.bash with dash, gwsh, Busybox ash, or FreeBSD sh,
> then test.ash simply waits forever on executing 'wait "$!"'.

Nice test. bash leaves the process in a state where SIGCHLD is blocked,
and the various ash-based shells do not unblock it. Because of that,
they do not pick up on the fact that the child process has terminated. I
would consider this a bug both in bash and in the ash-based shells.

Harald van Dijk

  reply	other threads:[~2020-02-07 11:19 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   ` Walter Harms [this message]
2020-02-07 14:33     ` AW: " 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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cbe5644f6db94eb89e4088141c426f8a@bfs.de \
    --to=wharms@bfs.de \
    --cc=bug-bash@gnu.org \
    --cc=busybox@busybox.net \
    --cc=dash@vger.kernel.org \
    --cc=harald@gigawatt.nl \
    --cc=jilles@stack.nl \
    --cc=kre@munnari.OZ.AU \
    --cc=martijn@inlv.org \


* 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).