DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 54GKuTqI023208
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A72023858416
Date: Sat, 17 May 2025 05:55:55 +0900
To: cygwin@cygwin.com
Subject: Re: FIFO hangs (Probably a bug of cygwin fifo)
Message-Id: <20250517055555.02f6adfd9670552531c1dd6e@nifty.ne.jp>
In-Reply-To: <ee7e023c-e5ba-4381-a9f3-e1cc595a730a@cornell.edu>
References: <20250514182934.ee8ff6c46ecfc44c69e70b72@nifty.ne.jp>
 <adf4f021-6a6f-4bc1-96db-f0ea5b9cd2f9@cornell.edu>
 <20250516084640.2b20feda1c8f65cddbd264bc@nifty.ne.jp>
 <20250516175923.680fc55b6aa2c3cd9d83199d@nifty.ne.jp>
 <ee7e023c-e5ba-4381-a9f3-e1cc595a730a@cornell.edu>
Mime-Version: 1.0
Precedence: list
From: Takashi Yano via Cygwin <cygwin@cygwin.com>
Reply-To: Takashi Yano <takashi.yano@nifty.ne.jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Fri, 16 May 2025 15:08:16 -0400
Ken Brown wrote:
> On 5/16/2025 4:59 AM, Takashi Yano via Cygwin wrote:
> > On Fri, 16 May 2025 08:46:40 +0900
> > Takashi Yano wrote:
> >> diff --git a/winsup/cygwin/local_includes/cygheap.h b/winsup/cygwin/local_includes/cygheap.h
> >> index fed87ec2b..7d11fbb37 100644
> >> --- a/winsup/cygwin/local_includes/cygheap.h
> >> +++ b/winsup/cygwin/local_includes/cygheap.h
> >> @@ -604,6 +604,8 @@ class cygheap_fdnew : public cygheap_fdmanip
> >>     {
> >>       if (cygheap->fdtab[fd])
> >>         cygheap->fdtab[fd]->inc_refcnt ();
> >> +    if (locked)
> >> +      cygheap->fdtab.unlock ();
> >>     }
> >>     void operator = (fhandler_base *fh) {cygheap->fdtab[fd] = fh;}
> >>   };
> > 
> > This should not be done, because the parent class cygheap_fdmanip
> > does that.
> Right.  But the other part of the patch (to syscalls.cc) looks right to 
> me, and I agree that it fixes the hang.  Here's my understanding of why 
> it works: The main thread tries to open the fifo for reading, but 
> fhandler_fifo::open blocks until it detects that someone is opening the 
> fifo for writing.  The other thread wants to do that, but it never gets 
> to the point of calling fhandler_fifo::open because it is stuck waiting 
> for the lock on cygheap->fdtab.  To fix this, we need to delay the 
> construction of the cygheap_fdnew object fd until after 
> fhandler_fifo::open has been called.
> 
> Do you agree with this explanation, or is there something else going on? 
>   In either case, I think it would be good to include at least a brief 
> explanation in your commit message, since this is a pretty subtle bug. 
> And thanks for finding the fix!

Thank you for confirming. I agree whth your explanation. I'd apply
the patch with above explanation.

Thanks!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

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