X-Recipient: archive-cygwin AT delorie DOT 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 AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT 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 DOT yano AT nifty DOT ne DOT 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 AT ispras DOT 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 AT cygwin DOT 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 AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Alexey Izbyshev via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Alexey Izbyshev <izbyshev AT ispras DOT ru>
Cc: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT 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 AT unified-streaming DOT com> wrote:
>> > >
>> > > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin <cygwin AT cygwin DOT 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