open descriptor to named pipes sometimes fail

open descriptor to named pipes sometimes fail

[sten.kristian.ivarsson]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

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 ?

Kristian

[-- Attachment #2: fifo.cpp --]
[-- Type: text/plain, Size: 952 bytes --]

#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int print_error(const int line, const int index, const int error)
{
   printf("%d\t%d\t%s\n", line, index, strerror(error));
   return error;
}

#define HANDLE_ERROR(result) do{if(result < 0){return print_error(__LINE__, idx, errno);}}while(0);

int main()
{
   const char *name = "/tmp/my_pipe";

   /* just in case it exists */
   remove(name);

   for (long idx = 0; idx < 1000; ++idx)
   {
      const int fifo = mkfifo(name, 0666) ? -1 : 0;
      HANDLE_ERROR(fifo);

      const int rfd = open(name, O_RDONLY | O_NONBLOCK);
      HANDLE_ERROR(rfd);

      const int wfd = open(name, O_WRONLY);
      HANDLE_ERROR(wfd);

      HANDLE_ERROR(close(wfd));
      HANDLE_ERROR(close(rfd));

      HANDLE_ERROR(unlink(name));
   }

   return 0;
}

Re: open descriptor to named pipes sometimes fail

[Ken Brown]

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?

Ken

Re: EXTERNAL: open descriptor to named pipes sometimes fail

[Wells, Roger K.]

On 4/7/20 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 ?

Kristian



I ran your code here. (many times)
uname -r   ->  Cygwin 3.1.4(0.340/5/3)
No problem




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



--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@leidos.com<mailto:roger.k.wells@leidos.com>

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

Re: Sv: Sv: open descriptor to named pipes sometimes fail

[Ken Brown]

On 4/8/2020 8:53 AM, Ken Brown via Cygwin wrote:
> 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.

This was not a well-thought-out change.  It creates a drastic slow-down.  I'll 
have to find a better solution.

Ken