DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 51PF9Nr23911926
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 51PF9Nr23911926
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=DPhIkqVZ
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E830F3858C54
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1740496161;
	bh=ydYZqqN23BoZkDoVMo3kDPj3UHchSlig3EZVBsK5K20=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=DPhIkqVZIBAYJYOTNMlHhZS5TFpkh/JXmB42wK8NgZMxgIrbPXQ2xtaUYPpTvM6Jk
	 erUlZAvmcjQZx5B6njWmYU9mXwANm6igScgXW1B2jU7SX7UTvYUVJAJrhH1LOQWw1H
	 /vqD9JJc6E0j7Ddy73O1p3WGP0o2gjgX3O9JsG0o=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC3CC3858D28
Date: Tue, 25 Feb 2025 16:08:54 +0100
To: cygwin AT cygwin DOT 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 AT cygwin DOT com
References: <fa85130b-9763-4b36-a431-1641667be253 AT anduin DOT net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa85130b-9763-4b36-a431-1641667be253@anduin.net>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="utf-8"
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>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 51PF9Nr23911926

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