Bogus exit code 127 from a child process
Takashi Yano
takashi.yano@nifty.ne.jp
Mon Mar 18 04:58:26 GMT 2024
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.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
More information about the Cygwin
mailing list