Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Robert Elz Newsgroups: gnu.bash.bug Subject: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait' Date: Fri, 07 Feb 2020 03:43:40 +0700 Lines: 47 Approved: bug-bash@gnu.org Message-ID: References: <10e3756b-5e8f-ba00-df0d-b36c93fa2281@inlv.org> <15235.1581021820@jinx.noi.kre.to> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1581022935 13752 209.51.188.17 (6 Feb 2020 21:02:15 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Martijn Dekker , DASH shell mailing list , busybox , Bug reports for the GNU Bourne Again SHell , Jilles Tjoelker To: Harald van Dijk Envelope-to: bug-bash@gnu.org In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2001:3c8:9009:181::2 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <15235.1581021820@jinx.noi.kre.to> X-Mailman-Original-References: <10e3756b-5e8f-ba00-df0d-b36c93fa2281@inlv.org> Xref: csiph.com gnu.bash.bug:15870 Date: Thu, 6 Feb 2020 19:29:41 +0000 From: Harald van Dijk Message-ID: =7C Nice test. Yes=21 =7C 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. (=22now=22 as in as of the past half hour...) =7C Because of that,=20 =7C they do not pick up on the fact that the child process has terminat= ed. 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 =22impossible to happen=22 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 investiga= te 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 cod= e has changed a lot in 9 (well, 9.0RC2 for now) which seems to have made th= e race a close call, instead of one sided. But that was not an artifact o= f the environment for the test, it happens for me on a real -8(ish) type system as well. kre