Bogus exit code 127 from a child process

[Alexey Izbyshev]

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