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 <dimi...@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
