pipe.cc: Missing FILE_SYNCHRONOUS_IO_NONALERT in call to NtOpenFile call in nt_create() - possibly leading to ENOSPC in UCRT

[Corinna Vinschen]

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