On Friday 18 January 2013 07:55:00 Chet Ramey wrote: > On 1/18/13 1:30 AM, Mike Frysinger wrote: > > this is somewhat a continuation of this thread: > > http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html > > > > i've gotten more or less the same report in Gentoo: > > http://bugs.gentoo.org/447810 > > > > the simple test case is: > > $ cat test.sh > > #!/bin/bash > > while :; do > > (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& (:)& > > while read x ; do : ; done < <(echo foo) > > done > > > > execute `./test.sh` and we see failures pretty much all the time. > > > > a simple patch to workaround/fix the issue by Yuta SATOH: > > --- bash-4.2/redir.c > > +++ bash-4.2/redir.c > > @@ -632,7 +632,9 @@ > > } > > else > > { > > - fd = open (filename, flags, mode); > > + do { > > + fd = open (filename, flags, mode); > > + } while ((fd < 0) && (errno == EINTR)); > > #if defined (AFS) > > if ((fd < 0) && (errno == EACCES)) > > { > > > > but we're not sure if this is the route to take ? seems like if bash is > > handling SIGCHLD, there's no avoiding this sort of check. > > Why is open returning -1/EINTR when the SIGCHLD handler is installed with > SA_RESTART? The intent is that opens get restarted even when bash handles > SIGCHLD.
i saw some signal() usage, but if it should all be using sigaction/SA_RESTART, i'll have them look along those lines to see if there are signals not being registered correctly (or if the kernel sucks and isn't handling SA_RESTART correctly). -mike
signature.asc
Description: This is a digitally signed message part.
