Sv: Sv: open descriptor to named pipes sometimes fail

[Ken Brown]

On 4/8/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
>> On 4/7/2020 2:38 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>> On 4/7/2020 11:10 AM, Kristian Ivarsson via Cygwin wrote:
>>>>> Opening a (second) descriptor for (blocking) write sometimes fail
>>>>>
>>>>> The provided test case sometimes succeed, but quite often fail with
>>>>> ENOENT (in various indexes)
>>>>>
>>>>> I haven't dug deeper to find the underlaying cause yet
>>>>>
>>>>> Have anyone experienced this before ?
>>>>
>>>> I can't reproduce this on my system.  I changed 1000 to 10000 and
>>>> then ran your test case 10 times, and it never failed.  I tested both
>>>> cygwin-3.1.4 and the HEAD of the topic/fifo branch (which I recently
>>>> force-pushed in case you want to try it).
>>>>
>>>> Can you run your test under strace and see if that provides a clue?
>>>
>>> I'm running things on a few year old laptop, perhaps with less muscles
>>> ;-)
>>>
>>> With strace it was harder to reproduce, but I could reproduce it (and
>>> it happen to be the first iteration this time)
>>
>> Does this help?
>>
>> --- a/winsup/cygwin/fhandler_fifo.cc
>> +++ b/winsup/cygwin/fhandler_fifo.cc
>> @@ -624,7 +624,8 @@ fhandler_fifo::open (int flags, mode_t)
>>                     else
>>                       goto success;
>>                   }
>> -             else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status))
>> +             else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status)
>> +                      | status == STATUS_OBJECT_NAME_NOT_FOUND)
>>                   continue;
>>                 else
>>                   {
> 
> Did you mean to use the bit-or-operator or the or-operator ?

The or-operator.  Thanks for catching that.

> I did
> ...
>     else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status) || status ==
> STATUS_OBJECT_NAME_NOT_FOUND)
> ...
> and with that change I cannot reproduce the error in the test-program

Great.  I'll push it to the topic/fifo branch.  For the record, that patch was 
motivated by your strace output, which showed NtOpenFile failing with status 
0xC0000034, which is STATUS_OBJECT_NAME_NOT_FOUND.

> We (with the open-source-application) do bump into some other issues later
> in the chanin, but I haven't investigated what the issues are yet (lack of
> time)
 >
>
> I'm a little confused why this "issue"/"report" didn't end up in the
> cygwin-mailing list and why it became us having a private conversation ?

That was unintentional.  I've added the list back to the Cc.

> We're grateful that you're taking your time to look into this. Do you have
> any clue of what the chances are to get these fixes (topic/fifo) into the
> master branch and finally into an official release (or at least a snap-shot)
> ?

It shouldn't be too much longer.  I'll regret making this prediction, but I'd 
guess that the branch will be ready for wider testing within a few weeks.

Ken