From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by sourceware.org (Postfix) with ESMTPS id A2783385800C for ; Sat, 6 Nov 2021 11:42:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2783385800C Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MIdS1-1mvgY60rUT-00EdhI for ; Sat, 06 Nov 2021 12:42:47 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 366DDA80D53; Sat, 6 Nov 2021 12:42:46 +0100 (CET) Date: Sat, 6 Nov 2021 12:42:46 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: 3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20211105123950.b118a7f2ba38379764df4c12@nifty.ne.jp> <20211105170542.96ce6dd4ca32880ddfddd660@nifty.ne.jp> <20211106044116.698b465a5d8ed6ce2cc75c99@nifty.ne.jp> <2cfa5de7-3b95-9062-4572-f36d304bc916@cornell.edu> <20211106151047.4d8f626bd6ebe9e4d8017f3b@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211106151047.4d8f626bd6ebe9e4d8017f3b@nifty.ne.jp> X-Provags-ID: V03:K1:NQmnctbH+W1Jct6T5lkogy+8L5JI+RTe5fKTwmDPb6lbU6x+nR4 KMAq4IIow9Qn2SdfdesASe48o++RB1PQ6C7V1swmz8VNDdyiZ5C4tyVwNstRo+/nKp1wr3H JhLG59OJUs8ewnlHZkKUexhZvKP4AVg65EuULArFAw0CwzRuV234wtCjhYd4wdaNcfEQJMB S7bodvcjRDPiN9izl0PKA== X-UI-Out-Filterresults: notjunk:1;V03:K0:88ejLnd6ttc=:dplC1k8HM6XEzCg48ZS8rC V/5TmBTeKjfttyt+Zjv2lzsdM4j2khq0Fv3MvAaHm3UpR5Yabht2B7hd8gCBqExxTEOZgUrKX ZAKkPT3w8cOw+EOGiwK3a3PKTLc44ECieNebsQHznb/2rKXtcwx+AKF0fMrL7G8QD29Vyg1du HI3Q6GC2RGrBT7ntC1elOeFswxjDLifkvhfFH7BZJi/4w8UjTE4SL2vV1icxYV3VFd25QY0Ui ZRmg4NAGU9CsZS5d3clLFwV5pNgELsioWIaDn7FxcXPlSTt5Yir+rmvGyFw8V80cGhnaEW9sZ oCi17HYKcBubUesdg9DZ1qDVYEE7gcZC2z0NfQlqOOdVK7tc9171inIP47C9rX5lvJHWwUydW TNUrt+GE90sj0Snqit5Gl4SReD3qw0rvOkKw4OAMIxGM4Z9bCPUakBKCHZ4wG7/nD+1QKAp0n 16H6L7I4GDU4tdz1DqJn+SghdOBNv3hTVALjte0GQ3qmF4vIEvfZeSF0p0M8PbOxTJAwIuk3Z R/ikpD8KOIapQbmPYjJb1eEoyXsMxSuv1Q+0AOqytR0tgETKBHQSqnbwPkZLi3UXKk7jHRnkV /P804uXEr6xXEQWSEVMnlrBNLxmiiBMs5tUus+iBNGQ65pNXqQzuwA7ZZZF7KzD7nNnEWqj1K sr3mPGpxjecZK7Cy9XRy8q7iAhzfyArTOgBQ86g5EeGeiCzj2Uuuu7M1W1mo60CBqPcOfGWdU A7r9GGsTxMNBVmbo X-Spam-Status: No, score=-105.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2021 11:42:50 -0000 On Nov 6 15:10, Takashi Yano wrote: > # This topic is moved from cygwin@cygwin.com mailing list. > > Hi Ken, > > On Fri, 5 Nov 2021 16:08:31 -0400 > Ken Brown wrote: > > On 11/5/2021 3:41 PM, Takashi Yano via Cygwin wrote: > > > Thanks much for the detailed steps. I could reproduce the problem. > > > > > > It seems that the cause is the overhaul for the pipe implementation. > > > I also found the workaround for this issue. Please try: > > > export CYGWIN=pipe_byte > > > > > > Corinna, Ken, > > > What about setting pipe mode to byte by default? > > > > I have a vague recollection that this caused some other problem, but I'll have > > to review the email discussions from a few months ago. I'm traveling at the > > moment and won't get to this for a few days. > > > > In the meantime, could you explain (probably on cygwin-developers) why message > > mode causes the reported issue? Also, does the problem occur only when there > > are non-Cygwin apps involved? > > I digged deeper this problem and might find the cause. > > Perhaps, C# program sometimes writes 0 byte to stdout. > As a result, if stdout is a message pipe, raw_read() returns > 0 byte and EOF is falsely detected. So, setting pipe type > to byte solves the issue. Given that EOF is reported as status STATUS_END_OF_FILE, wouldn't it make sense to just check for 0 bytes in raw_read and continue the loop as if literally nothing has happened? > diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc > index 43771e8f7..bc06d157c 100644 > --- a/winsup/cygwin/fhandler_pipe.cc > +++ b/winsup/cygwin/fhandler_pipe.cc > @@ -393,7 +393,8 @@ fhandler_pipe::raw_read (void *ptr, size_t& len) > } > } > > - if (nbytes_now == 0 || status == STATUS_BUFFER_OVERFLOW) > + if ((nbytes_now == 0 && !NT_SUCCESS (status)) > + || status == STATUS_BUFFER_OVERFLOW) > break; > } > ReleaseMutex (read_mtx); Oh, heh. > I am not sure which is the better solution. Me neither. I remember that using a message type pipe fixed some problem of old, but just because message pipes were a solution in the past... A quick search uncovered that the message type pipes have been introduced in April 2012. We might have to search the mailing list archives to fiund the reason. The question is if that problem is still present in the overhauled code at all. > P.S. > Unfortunately, these solutions do not resolve the issue > which is another issue with C# program: > https://cygwin.com/pipermail/cygwin/2021-March/247987.html > This still needs FILE_SYNCHRONOUS_IO_NONALERT flag. If we want to add FILE_SYNCHRONOUS_IO_NONALERT, this would have to be solved by running NtReadFile/NtWriteFile synchronously in a thread, started on every invocation of raw_read/raw_write. raw_read/raw_write would then call cygwait on the thread object. To break on signal or thread cancallation events, it would have to call CancelSynchronousIo. That's certainly doable. Corinna