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.y...@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
