On Tue, 19 May 2020 09:37:17 -0400 Ken Brown via Cygwin-patches <[email protected]> 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 <[email protected]> wrote: > >>> Hi Ken, > >>> > >>> On Mon, 18 May 2020 13:42:19 -0400 > >>> Ken Brown via Cygwin-patches <[email protected]> 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 <[email protected]> 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 <[email protected]>
