X-Recipient: archive-cygwin@delorie.com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 489AE3858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1710760193;
	bh=be16f2Qa1YolfvCcUz3yMX1kuIE8GFLgWXqymKyrEMo=;
	h=Date:To:Subject:In-Reply-To:List-Id:List-Unsubscribe:List-Archive:
	 List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:From;
	b=QKTedMUqBjf875oqSNDidGrpTx3roOdatl7PCGeCLByHvoSdPqLj9WQmDBsIwVJHI
	 QtW+kP4o2d/AbLq6B335BRG2gSxUfR8D9rjIjRJo1lO3sTNicEbk4sT8DU6o+xg2AN
	 RshugWTZoXP4Pu5D03qE5RSgdQkUvTQccSJ7FK5Q=
X-Original-To: cygwin@cygwin.com
Delivered-To: cygwin@cygwin.com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D157C3858D1E
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D157C3858D1E
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710760138; cv=none;
 b=UQUl0a2/HRos690ZMS75IRbLWBhXvD7vBU6p1mgEgSTFaR5wHzquA5cJTVkXYkjeT2upJA73IYTvQxOm539hMTyriTIyHQAvYUEbQKXmMl7otlGrUIZsLiIwn4Scny1sYG68P4gOvs1mQo9XR09HxGKKD+E8a1O4z+8HHv4LAWE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1710760138; c=relaxed/simple;
 bh=Ix6jXxokYMgh19TaU8cyWAXW3nseTeOwhegFthr3uvw=;
 h=DKIM-Signature:MIME-Version:Date:From:To:Subject:Message-ID;
 b=mPNundsvXm/2cFKAnGY/bC+DwQMlQx3JN8Nvpsak8OtbzUkCyBzqydxLdsQE5wo8DZI+tanu/Hg9xRZDkTkGSRsNXqnq/DKK7rQcmRCA6hLy9m1UZ1QKK+lS7hrdZKMN3Hq15cFaZidcgKEIY2H/m3GHIcHlPbBywJhvDuAiZS4=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru D98A94076749
MIME-Version: 1.0
Date: Mon, 18 Mar 2024 14:08:53 +0300
To: takashi.yano@nifty.ne.jp
Subject: Re: Bogus exit code 127 from a child process
In-Reply-To: <20240318135826.e4176868074e074eb3138cb5@nifty.ne.jp>
User-Agent: Roundcube Webmail/1.4.13
Message-ID: <6cdb036ad7bbc1227a470dcd8f105544@ispras.ru>
X-Sender: izbyshev@ispras.ru
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin@cygwin.com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-request@cygwin.com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=subscribe>
From: Alexey Izbyshev via Cygwin <cygwin@cygwin.com>
Reply-To: Alexey Izbyshev <izbyshev@ispras.ru>
Cc: cygwin@cygwin.com
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 42IB9s1X323705

On 2024-03-18 07:58, Takashi Yano wrote:
> On Mon, 18 Mar 2024 12:09:06 +0900
> Takashi Yano wrote:
>> On Sun, 17 Mar 2024 14:10:55 +0100
>> Dimitry Andric wrote:
>> > On 17 Mar 2024, at 13:50, Dimitry Andric <dimitry@unified-streaming.com> wrote:
>> > >
>> > > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin <cygwin@cygwin.com> wrote:
>> > > ...
>> > >>
>> > >> I also test your test case:
>> > >> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done
>> > >> in Linux (Debian 12.5), and the issue reproduced!
>> > >
>> > > Yeah, same here with bash 5.1.16(1)-release on Ubuntu 22.04. It errors out with 127 after ~50-200 loops.
>> >
>> > Having built bash master (bash-5.2-27-gf3b6bd19) here, it consistently gives 127 in this area:
>> >
>> > https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/wait.def#n227
>> >
>> >    211  #if defined (JOB_CONTROL)
>> >    212    if (nflag)
>> >    213      {
>> >    214        if (list)
>> >    215          {
>> >    216            opt = set_waitlist (list);
>> >    217            if (opt == 0)
>> >    218              WAIT_RETURN (127);
>> >    219            wflags |= JWAIT_WAITING;
>> >    220          }
>> >    221
>> >    222        status = wait_for_any_job (wflags, &pstat);
>> >    223        if (vname && status >= 0)
>> >    224          builtin_bind_var_to_int (vname, pstat.pid, bindflags);
>> >    225
>> >    226        if (status < 0)
>> > => 227          status = 127;
>> >    228        if (list)
>> >    229          unset_waitlist ();
>> >    230        WAIT_RETURN (status);
>> >    231      }
>> >    232  #endif
>> >
>> > So for some reason, wait_for_any_job() returns a negative value in this particular situation.
>> 
>> Line 218 looks also suspicious.
> 
> Probably, this is not a bug. man bash says:
>               If  the  -n option is supplied, wait waits for a single 
> job from
>               the list of ids or, if no ids are supplied, any job, to 
> complete
>               and returns its exit status.  If none of the supplied  
> arguments
>               is a child of the shell, or if no arguments are supplied 
> and the
>               shell  has no unwaited‐for children, the exit status is 
> 127.
> 
> If the background process exited before calling 'wait -n', it returns 
> 127.
> This is very different from wait() system call, which is necessary for
> any background joubs, otherwise zombie remains.
> 
> In the shell, it is not necessary to call wait command for background 
> jobs,
> therefore exit status of the background job which already exited is not 
> held
> anymore.
> 
> So, actual bug is in the test case.

I missed the subthread starting from your bash version request due to 
not being CCed, so replying via the mail archive link.

I'm sorry for wasting your time with the bad test case. I should have 
tested on Linux first myself. Thank you, Takashi and Dimitry.

The original problem with make that I was reproducing doesn't involve 
"wait -n" or any bash background jobs though, so this puts me back to 
the point before (I thought) I eliminated make. I'll try my older 
reproducers with new Cygwin versions, and will probably look at make 
source code (since it's starting to look like it might be a bug in make, 
not in Cygwin) before posting further.

Thanks,
Alexey


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

