DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 51PF9Nr23911926
Date: Tue, 25 Feb 2025 16:08:54 +0100
To: cygwin@cygwin.com
Subject: Re: pipe.cc: Missing FILE_SYNCHRONOUS_IO_NONALERT in call to
 NtOpenFile call in nt_create() - possibly leading to ENOSPC in UCRT
Message-ID: <Z73dBsUPT4UeAqt6@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <fa85130b-9763-4b36-a431-1641667be253@anduin.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa85130b-9763-4b36-a431-1641667be253@anduin.net>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

Hi Knut,

On Feb 25 01:51, knut st. osmundsen via Cygwin wrote:
> Hi,
> 
> I've been hunting an issue for some days now, where a non-cygwin program
> using microsoft's UCRT sometimes end up with a sticky error on stdout when
> running under cygwin perl with a pipe capturing stdout and stderr.  When the
> problem triggers, the pipe buffer appears to be full and it really looks
> like it's hitting the errno=ENOSPC/doserrno=0 situation at the tail end of
> _write_nolock() in ucrt/lowio/write.cpp.
> 
> I *think* the issue is that the write end of the pipe isn't configured to be
> synchronous.  In winsup/cygwin/fhandler/pipe.cc, the nt_create() function
> sets FILE_SYNCHRONOUS_IO_NONALERT when creating the _read_ end of the pipe
> using NtCreateNamedPipeFile, citing some C# program compatibility need. 
> But, the call to NtOpenFile below that opens the _write_ end of the pipe
> doesn't set it.  It does set the SYNCHRONIZE access right, but doesn't set
> the FILE_SYNCHRONOUS_IO_NONALERT flag (last parameter, is zero). This is
> akin to calling CreateFile with FILE_FLAG_OVERLAPPED, if I understand it
> correctly.

We can't make the write side of the pipe synchronous easily, because
this means a pretty big rewrite of the current code.  Right now, if
we'd add the FILE_SYNCHRONOUS_IO_NONALERT, you couldn't interrupt
NtWriteFile with a signal.

We can add such a change to the TODO list for 3.7, using NtWriteFile
in a thread or something like that.

However, maybe there's a chance we can fix this for 3.6, if you would
be able to create simple testcase in plain C, reproducing your issue,
and the actual problem is not the FILE_SYNCHRONOUS_IO_NONALERT.

> Also, in the error path of the NtOpenFile call, GetLastError() is used
> instead of __seterrno_from_nt_status() or RtlNtStatusToDosError().

Thanks, I'll definitely fix that for 3.6.


Thanks,
Corinna

-- 
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