[PATCH 00/21] FIFO: Support multiple readers

[Takashi Yano]

On Tue, 19 May 2020 09:37:17 -0400
Ken Brown via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
> On 5/19/2020 8:51 AM, Ken Brown via Cygwin-patches wrote:
> > On 5/19/2020 2:15 AM, Takashi Yano via Cygwin-patches wrote:
> >> On Tue, 19 May 2020 10:26:09 +0900
> >> Takashi Yano via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
> >>> Hi Ken,
> >>>
> >>> On Mon, 18 May 2020 13:42:19 -0400
> >>> Ken Brown via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
> >>>> Hi Takashi,
> >>>>
> >>>> On 5/18/2020 12:03 PM, Ken Brown via Cygwin-patches wrote:
> >>>>> On 5/18/2020 1:36 AM, Takashi Yano via Cygwin-patches wrote:
> >>>>>> On Mon, 18 May 2020 14:25:19 +0900
> >>>>>> Takashi Yano via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
> >>>>>>> However, mc hangs by several operations.
> >>>>>>>
> >>>>>>> To reproduce this:
> >>>>>>> 1. Start mc with 'env SHELL=tcsh mc -a'
> >>>>>>
> >>>>>> I mean 'env SHELL=/bin/tcsh mc -a'
> >>>>>>
> >>>>>>> 2. Select a file using up/down cursor keys.
> >>>>>>> 3. Press F3 (View) key.
> >>>>>
> >>>>> Thanks for the report.  I can reproduce the problem and will look into it.
> >>>>
> >>>> I'm not convinced that this is a FIFO bug.  I tried two things.
> >>>>
> >>>> 1. I attached gdb to mc while it was hanging and got the following backtrace
> >>>> (abbreviated):
> >>>>
> >>>> #1  0x00007ff901638037 in WaitForMultipleObjectsEx ()
> >>>> #2  0x00007ff901637f1e in WaitForMultipleObjects ()
> >>>> #3  0x0000000180048df5 in cygwait () at ...winsup/cygwin/cygwait.cc:75
> >>>> #4  0x000000018019b1c0 in wait4 () at ...winsup/cygwin/wait.cc:80
> >>>> #5  0x000000018019afea in waitpid () at ...winsup/cygwin/wait.cc:28
> >>>> #6  0x000000018017d2d8 in pclose () at ...winsup/cygwin/syscalls.cc:4627
> >>>> #7  0x000000018015943b in _sigfe () at sigfe.s:35
> >>>> #8  0x000000010040d002 in get_popen_information () at filemanager/ext.c:561
> >>>> [...]
> >>>>
> >>>> So pclose is blocking after calling waitpid.  As far as I can tell from looking
> >>>> at backtraces of all threads, there are no FIFOs open.
> >>>>
> >>>> 2. I ran mc under strace (after exporting SHELL=/bin/tcsh), and I didn't see
> >>>> anything suspicious involving FIFOs.  But I saw many EBADF errors from fstat 
> >>>> and
> >>>> close that don't appear to be related to FIFOs.
> >>>>
> >>>> So my best guess at this point is that the FIFO changes just exposed some
> >>>> unrelated bug(s).
> >>>>
> >>>> Prior to the FIFO changes, mc would get an error when it tried to open 
> >>>> tcsh_fifo
> >>>> the second time, and it would then set
> >>>>
> >>>>     mc_global.tty.use_subshell = FALSE;
> >>>>
> >>>> see the mc source file subshell/common.c:1087.
> >>>
> >>> I looked into this problem and found pclose() stucks if FIFO
> >>> is opened.
> >>>
> >>> Attached is a simple test case. It works under cygwin 3.1.4,
> >>> but stucks at pclose() under cygwin git head.
> >>>
> >>> Isn't this a FIFO related issue?
> >>
> >> In the test case, fhandler_fifo::close() called from /bin/true
> >> seems to get into infinite loop at:
> >>
> >> do
> >> ...
> >> while (inc_nreaders () > 0 && !found);
> > 
> > Thank you!  I see the problem.  After the popen call, the original 
> > fhandler_fifo's fifo_reader_thread was no longer running, so it was unable to 
> > take ownership.
> > 
> > It might take a little while for me to figure out how to fix this.
> 
> Actually, I think it's easy.  Please try the two attached patches.  The second 
> one is the crucial one for the mc problem, but the first is something I noticed 
> while working on this.
> 
> I just did a quick and dirty patch for testing purposes.  I still have to do a 
> lot of cleanup and make sure the fix doesn't break something else.

For a shor time, I tested these patches, and confirmed
that this fixes the problem.

Thanks for the quick response.

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