DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5954wVkn1958644
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 5954wVkn1958644
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=MKGiL5SJ
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 385073858CB6
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1759640309;
	bh=be43fRkBfEMCyHZp3xBJpZlTRmJlUPczuBG3yiG+jns=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=MKGiL5SJ15TD7Kc9U2zKRZhDyANQ7bmgpar+W0LtlxBtoPWjj+S7269zlHYdEoSKe
	90ge1py7aVJrvi61J/ECahFGiQMM9GaQ1YsGDkcenf83EASfmJHMZcfXcQMCGgzPPi
	l5bHbGD39RsqAdOkN5gZqI4+dD5lsZVKMVw+f8/g=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org C1C293858D1E
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org C1C293858D1E
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759640281; cv=none;
	b=sLhB0UJS5WHbROErmQhevKGEKVC1bAPAu9YKdc3wrkphbbnehymj4Qc3mA+zbwXwde/HDdDoZHsifzzXtyilyvuqadCjkg1SfqAL+0rS44YuU2qv6Z1Z3OF16qUMHb5m+xDALKyK//zQ3IEs/6p8mmsD78zCDg52LY6ajC+Kyro=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1759640281; c=relaxed/simple;
	bh=ybb0HkCAoyCTneDC/B38Je7tixaY6lCeS9aC3IMk2ZM=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=UUSMwv8u5RlUGSU6EcpFfJ9H4ItI8UE1OSLZZXvlBiVE6drE0JdBQ9i29lZRpTN6cnXA01lqeAk2uS2GuZL0W2yt9Dtr1+6GNSumS4JtUuVCP9xxDPMDKES12O1+a/0i3aMCUavuAUcj+H26LEjGjmI1TSRq6Eo+WzdsTllZ3LA=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org C1C293858D1E
Date:	Sun, 5 Oct 2025 15:57:56 +1100
To:	cygwin AT cygwin DOT com
Subject:	Re: bash hangs when executing a script with a here document larger
	than 64 KiB
Message-ID:	<aOH61MY8W2lZMWWb@dimstar.local.net>
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<6844953 DOT 4vTCxPXJkl AT nimes>
	<6f388d6d-e0b1-46a6-a4fb-9f1e008345a7 AT SystematicSW DOT ab DOT ca>
MIME-Version:	1.0
In-Reply-To:	<6f388d6d-e0b1-46a6-a4fb-9f1e008345a7@SystematicSW.ab.ca>
X-Atmail-Id:	duncan_roe AT optusnet DOT com DOT au
X-atmailcloud-spam-action:	no action
X-Cm-Analysis:	v=2.4 cv=SOxEVvvH c=1 sm=1 tr=0 ts=68e1fad6
	a=6uXT7DF6Lsg9xELlzDb1tA==:117 a=6uXT7DF6Lsg9xELlzDb1tA==:17
	a=PgLrZpBLtpqfETd_:21 a=kj9zAlcOel0A:10 a=x6icFKpwvdMA:10 a=mDV3o1hIAAAA:8
	a=4RmgR_PwcKbOctx3FY4A:9 a=CjuIK1q_8ugA:10 a=RKkw-53RgDYA:10
X-Cm-Envelope:	MS4xfOySObBjqZsaOWgEkFkZlJd1rKlJ4FClChQI1v1ZXmBykxz4PFiAQg3lJ9Umhv2sj6beDquexZqkLlhFJaf5sTEt3OG0fLVXDLB0m7KvYkog5aOu2l7p
	djQ27zx6ImixUmPU1o0mukIaqkRSkZFo9kV8BmJRCBkcz1hEelDd+x3uYUW9MaCLl7KDvs/kZz8uFA==
X-atmailcloud-route:	unknown
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Duncan Roe via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Duncan Roe <duncan_roe AT optusnet DOT com DOT au>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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

- Raw text -