* open descriptor to named pipes sometimes fail @ 2020-04-07 15:10 sten.kristian.ivarsson 2020-04-07 16:01 ` Ken Brown 2020-04-07 17:29 ` EXTERNAL: " Wells, Roger K. 0 siblings, 2 replies; 5+ messages in thread From: sten.kristian.ivarsson @ 2020-04-07 15:10 UTC (permalink / raw) To: 'cygwin' [-- 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; } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: open descriptor to named pipes sometimes fail 2020-04-07 15:10 open descriptor to named pipes sometimes fail sten.kristian.ivarsson @ 2020-04-07 16:01 ` Ken Brown [not found] ` <001301d60d0b$c9064140$5b12c3c0$@gmail.com> 2020-04-07 17:29 ` EXTERNAL: " Wells, Roger K. 1 sibling, 1 reply; 5+ messages in thread From: Ken Brown @ 2020-04-07 16:01 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <001301d60d0b$c9064140$5b12c3c0$@gmail.com>]
[parent not found: <345452a5-3c38-4aa6-85ed-78939412c047@cornell.edu>]
[parent not found: <003c01d60d83$07aa3380$16fe9a80$@gmail.com>]
* Re: Sv: Sv: open descriptor to named pipes sometimes fail [not found] ` <003c01d60d83$07aa3380$16fe9a80$@gmail.com> @ 2020-04-08 12:53 ` Ken Brown 2020-04-08 18:49 ` Ken Brown 0 siblings, 1 reply; 5+ messages in thread From: Ken Brown @ 2020-04-08 12:53 UTC (permalink / raw) To: sten.kristian.ivarsson; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Sv: Sv: open descriptor to named pipes sometimes fail 2020-04-08 12:53 ` Sv: Sv: " Ken Brown @ 2020-04-08 18:49 ` Ken Brown 0 siblings, 0 replies; 5+ messages in thread From: Ken Brown @ 2020-04-08 18:49 UTC (permalink / raw) To: sten.kristian.ivarsson; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EXTERNAL: open descriptor to named pipes sometimes fail 2020-04-07 15:10 open descriptor to named pipes sometimes fail sten.kristian.ivarsson 2020-04-07 16:01 ` Ken Brown @ 2020-04-07 17:29 ` Wells, Roger K. 1 sibling, 0 replies; 5+ messages in thread From: Wells, Roger K. @ 2020-04-07 17:29 UTC (permalink / raw) To: cygwin 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-08 18:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-07 15:10 open descriptor to named pipes sometimes fail sten.kristian.ivarsson 2020-04-07 16:01 ` Ken Brown [not found] ` <001301d60d0b$c9064140$5b12c3c0$@gmail.com> [not found] ` <345452a5-3c38-4aa6-85ed-78939412c047@cornell.edu> [not found] ` <003c01d60d83$07aa3380$16fe9a80$@gmail.com> 2020-04-08 12:53 ` Sv: Sv: " Ken Brown 2020-04-08 18:49 ` Ken Brown 2020-04-07 17:29 ` EXTERNAL: " Wells, Roger K.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).