Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Sun, 18 Aug 2002 02:08:43 +0200 From: Pavel Tsekov Reply-To: Pavel Tsekov X-Priority: 3 (Normal) Message-ID: <57228872451.20020818020843@gmx.net> To: cygwin-developers AT cygwin DOT com CC: mc-devel AT gnome DOT org Subject: Another problem with MC + subshell on Cygwin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, there! :) The patch from yesterday fixed a problem, but it exposed another one :( For Cygwin people looking at this the following link would be of interest: http://mail.gnome.org/archives/mc-devel/2002-August/msg00040.html It describes how MC + subshell works. The problem: MC would hang repeatedly on select () waiting for data from the subshell. See the stacktraces at the moment of the hang. -> Midnight Commander #0 0x7ffe0304 in ?? () #1 0x77e54c70 in _system_dlls__ () #2 0x61071384 in select_stuff::wait (this=0x22f9a4, readfds=0x22f90c, writefds=0x22f8fc, exceptfds=0x22f8ec, ms=4294967295) at ../../../../cygwin-snapshot/winsup/cygwin/select.cc:265 #3 0x61070bd7 in cygwin_select (maxfds=64, readfds=0x22fafc, writefds=0x22f92c, exceptfds=0x22f91c, to=0x0) at ../../../../cygwin-snapshot/winsup/cygwin/select.cc:156 #4 0x004482de in feed_subshell (how=0, fail_on_error=0) at ../../mc-4.5.99a/src/subshell.c:965 -> Bash #0 0x7ffe0304 in ?? () #1 0x61013299 in sig_handle_tty_stop (sig=17) at ../../../../cygwin-snapshot/winsup/cygwin/exceptions.cc:618 #2 0x61014f87 in sigreturn () at ../../../../cygwin-snapshot/winsup/cygwin/exceptions.cc:1178 #3 0x0042493c in kill_pid (pid=548, sig=17, group=0) at ../bash-2.05b-3/jobs.c:2387 #4 0x004646ae in kill_builtin (list=0xa025588) at ../../bash-2.05b-3/builtins/../../bash-2.05b-3/builtins/kill.def:171 #5 0x00416d1e in execute_builtin (builtin=0x4643e0 , words=0xa025690, flags=0, subshell=0) at ../bash-2.05b-3/execute_cmd.c:2825 Finally I was able to determine the source of the problem, or at least it seem so :) Below is an strace of Bash along with some comments from me, which should provide the necessary information. >>>>> Bash stops (SIGSTOP) itself after command is processed 1460 477713226 [main] bash 660 _kill: kill (660, 17) 50 477713276 [main] bash 660 sig_send: pid 660, signal 17, its_me 1 47 477713323 [sig] bash 660 wait_sig: awake 42 477713365 [sig] bash 660 wait_sig: processing signal 17 34 477713399 [sig] bash 660 wait_sig: Got signal 17 33 477713432 [sig] bash 660 sig_handle: signal 17 >>>>> Preparing everything to call sig_handle_tty_stop 37 477713469 [sig] bash 660 sig_handle: signal 17, about to call 0x61013158 >>>>> setup_handler routine ... 78 477713547 [sig] bash 660 interruptible: pc 0x61075E81, h 0x61000000, interruptible 0, testvalid 0 69 477713616 [sig] bash 660 interruptible: pc 0x41D6F5, h 0x400000, interruptible 1, testvalid 0 39 477713655 [sig] bash 660 proc_subproc: args: 3, 1 35 477713690 [sig] bash 660 proc_subproc: clear waiting threads 35 477713725 [sig] bash 660 proc_subproc: finished clearing 34 477713759 [sig] bash 660 proc_subproc: returning 1 >>>>> Strange !!! We'are missing a sigproc_printf output here (sigproc.cc, 675) >>>>> Oh, well... it's not so important though :)) 39 477713798 [main] bash 660 sig_send: Waiting for thiscomplete 0x70C 38 477713836 [sig] bash 660 interrupt_setup: armed signal_arrived 0x798, res 1 37 477713873 [sig] bash 660 setup_handler: good. Didn't suspend main thread, th 0x610CC440 37 477713910 [sig] bash 660 setup_handler: returning 1 >>>>> End of setup_handler () 34 477713944 [sig] bash 660 sig_handle: returning 1 40 477713984 [main] bash 660 sig_send: returning 0 from sending signal 17 34 477714018 [main] bash 660 kill_worker: 0 = kill_worker (660, 17) >>>>> Just before calling sig_handle_tty_stop () ... sigdelayed () 36 477714054 [main] bash 660 reset_signal_arrived: reset signal_arrived 35 477714089 [main] bash 660 set_process_mask: old mask = 0, new mask = 0 42 477714131 [main] bash 660 set_process_mask: not calling sig_dispatch_pending. sigtid 0xC1C current 0x700 42 477714173 [sig] bash 660 wait_sig: set main thread completion event 35 477714208 [sig] bash 660 wait_sig: looping >>>>> sig_handle_tty_stop () 42 477714250 [main] bash 660 my_parent_is_alive: parent still alive >>>>> Send SIGCHLD to parent (MC) 93 477714343 [main] bash 660 sig_send: pid 3008, signal 20, its_me 0 40 477714383 [main] bash 660 getsem: pid 3008, ppid 184, wait 1000, initializing 0 >>>>> The thread is not suspended yet, and SIGCONT from MC is received. 986 477715369 [sig] bash 660 wait_sig: awake 110 477715479 [sig] bash 660 wait_sig: processing signal 19 35 477715514 [sig] bash 660 wait_sig: Got signal 19 34 477715548 [sig] bash 660 sig_handle: signal 19 635 477716183 [main] bash 660 sig_send: Not waiting for sigcomplete. its_me 0 signal 20 86 477716269 [main] bash 660 sig_send: returning 0 from sending signal 20 >>>>> Just before Bash is suspended.... 56 477716325 [main] bash 660 sig_handle_tty_stop: process 660 stopped by signal 17, myself->ppid_handle 0x7F8 >>>>> As part of SIGCONT processing SuspendThread () is called and then >>>>> ResumeThread () to resume the thread. What happens if the >>>>> SuspendThread () from sig_handle_tty_stop () is called after that. >>>>> Bash will be suspended, but MC will think it is actually running :( 48 477716373 [sig] bash 660 sig_handle: default signal 19 ignored 40 477716413 [sig] bash 660 sig_handle: returning 0 39 477716452 [sig] bash 660 wait_sig: looping 43 477716495 [sig] bash 660 wait_sig: awake 40 477716535 [sig] bash 660 wait_sig: looping So MC tries to select () from the subshell, but it is stopped. I think a quick and dirty workaround for MC is to put some kind of timeout before sending SIGCONT and hope for the best. The best solution will be to fix this on Cygwin of course :) I haven't thinked of any solution since I've just found it and I'm going to bed since it's 2 AM here :) Thanks! Pavel Tsekov