On Thu, Sep 18, 2025 at 02:17:12PM -0600, cygwin wrote:
> On 2025-09-18 13:09, Bruno Haible via Cygwin wrote:
> > Please, can you handle this bug report, specific to Cygwin?
> > The GNU bash maintainer cannot reproduce it, as he doesn't use Cygwin.
> >
> > https://lists.gnu.org/archive/html/bug-bash/2025-09/msg00186.html
>
> Confirm it hangs in bash but not with dash/ash:
>
> $ dash ./here-toobig.sh
> here-toobig.sh: error: cannot find input file: 'Makefile.in'
> $ grep -nC3 echo\ \'BEGIN here-toobig.sh
> 861- ac_cs_awk_cr=$ac_cr
> 862-fi
> 863-
> 864:echo 'BEGIN {' >"$ac_tmp/subs1.awk" &&
> 865-cat >>"$ac_tmp/subs1.awk" <<\_ACAWK &&
> 866-S["gltests_libgnu_LIBOBJDEPS"]=""
> 867-S["gltests_libgnu_LTLIBOBJS"]=""
> $ awk '866 <= FNR && FNR <= 2710' here-toobig.sh | wc -lwmcL
> 1845 2041 65563 65563 177
>
> and Cygwin works with 64KB "pages" and temp buffer sizes.
>
This only affects here documents over 64KB by 128 bytes or less. The underlying
cause is a bug in Windows or Cygwin which damages the build process.
Bash tries to send here document data to the target via a pipe. It has to write
the entire document to the pipe before any of it get read. Bash checks that the
system it's running on can accept that much data in a pipe, otherwise bash uses
a temporary file.
In redir.c, bash first checks that the here document is smaller than the pipe
capacity calculated at build time. This value is wrong because of the bug.
Bash then re-checks the pipe capacity using fcntl(F_GETPIPE_SZ) if that fcntl is
available. Under cygwin it is not.
The build process runs psize.aux (built from builtins/psize.c) to get pipe
capacity. Below is a condensed free-standing version of psize.c (no bash
includes nor GNU header):-
| /* psize.c - Find pipe size. */
|
| /* Copyright (C) 1987, 1991 Free Software Foundation, Inc.
| Copyright (C) 2025 Duncan Roe
| */
|
| /* Write output in 128-byte chunks until we get a sigpipe or write gets an
| EPIPE. Then report how many bytes we wrote. We assume that this is the
| pipe size. */
|
| #include <unistd.h>
| #include <stdio.h>
| #include <signal.h>
| #include <errno.h>
| #include <stdlib.h>
| #include <string.h>
| #include <unistd.h>
|
| int nw;
|
| static void
| sigpipe (int sig, siginfo_t *siginfo, void *ucontext)
| {
| fprintf (stderr, "%d\n", nw);
| exit (0);
| }
|
| int
| main (int argc, char **argv)
| {
| char buf[128];
| register int i;
| static struct sigaction act;
|
| for (i = 0; i < 128; i++)
| buf[i] = ' ';
|
| memset(&act, 0, sizeof act);
| act.sa_sigaction = sigpipe;
| act.sa_flags = SA_SIGINFO;
| sigemptyset(&act.sa_mask);
| sigaddset(&act.sa_mask, SIGPIPE);
| sigaction(SIGPIPE, &act, NULL);
|
| nw = 0;
| for (;;)
| {
| int n;
| n = write (1, buf, 128);
| nw += n;
| }
| return (0);
| }
`make` runs this as `psize.aux | sleep 3` which gives plenty of time to fill the
pipe before getting SIGPIPE when it outputs how much it has written.
To see what goes wrong, first build psize.exe:-
| gcc psize.c -g3 -gdwarf-5 -o psize
Now run psize with a longer sleep time so you can attach gdb to it and enter a
few commands (I used sleep 300 and killed sleep once gdb was ready)(blank lines
omitted):-
| Script started on 2025-10-04 21:24:09+10:00 [TERM="xterm-direct"
TTY="/dev/pty1" COLUMNS="88" LINES="98"]
| 21:24:11$ gdb -q -p $(pgrep psize)
| Attaching to process 9764
| [New Thread 9764.0x11c0]
| [New Thread 9764.0x38ac]
| [New Thread 9764.0x3740]
| Reading symbols from /home/dunc/tests/psize/psize.exe...
| (gdb) watch nw
| Hardware watchpoint 1: nw
| (gdb) b sigpipe
| Breakpoint 2 at 0x100401096: file psize.c, line 24.
| (gdb) c
| Continuing.
| [Thread 9764.0x3740 exited with code 0]
| [Switching to Thread 9764.0x50c]
| Thread 1 "psize" hit Hardware watchpoint 1: nw
| Old value = 65536
| New value = 65664
| main (argc=1, argv=0xa000004e0) at psize.c:47
| 47 {
| (gdb) n
| 49 n = write (1, buf, 128);
| (gdb)
| Thread 1 "psize" received signal SIGPIPE, Broken pipe.
| 0x00007ffeeefcd574 in ntdll!ZwWaitForSingleObject ()
| from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
| (gdb) signal SIGPIPE
| Continuing with signal SIGPIPE.
| Thread 1 "psize" hit Breakpoint 2, sigpipe (sig=13, siginfo=0x7ffffbdd0,
| ucontext=0x7ffffbf50) at psize.c:24
| 24 fprintf (stderr, "%d\n", nw);
| (gdb) n
| 25 exit (0);
| (gdb)
| [Thread 9764.0x50c exited with code 0]
| [Thread 9764.0x38ac exited with code 0]
| [Inferior 1 (process 9764) exited normally]
| (gdb) q
| 21:27:59$ s
| exit
| Script done on 2025-10-04 21:28:17+10:00 [COMMAND_EXIT_CODE="0"]
SIGPIPE interrupts write() which returns 128 as if it had succeeded!
The signal is only delivered to psize after it tries another write().
There has to be a bug in there somewhere.
If the bug is to persist, I suggest to munge psize.c:-
| *** builtins/psize.c.bu Fri Aug 15 05:56:53 2008
| --- builtins/psize.c Sun Oct 5 14:06:50 2025
| ***************
| *** 51,57 ****
| sigpipe (sig)
| int sig;
| {
| ! fprintf (stderr, "%d\n", nw);
| exit (0);
| }
|
| --- 51,57 ----
| sigpipe (sig)
| int sig;
| {
| ! fprintf (stderr, "%d\n", nw - 128);
| exit (0);
| }
|
N.B. blank lines (after removing 1st 2 chars) have 2 trailing spaces.
Cheers ... Duncan.
--
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
