Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 18 Jun 2004 09:58:16 +0200 (MEST) From: bse2000 AT gmx DOT de To: cygwin AT cygwin DOT com MIME-Version: 1.0 References: Subject: PLEASE HELP: TCSH does exit when sending SIGHUP X-Authenticated: #19221175 Message-ID: <6504.1087545496@www21.gmx.net> X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Cygwin gurus, I opened a threat in cygwin-xfree http://cygwin.com/ml/cygwin-xfree/2004-06/msg00136.html because I thought it is an X problem. However, Igor and me found out that it seems to be a general TCSH issue related to my latest Cygwin update. We isolated the problem to TCSH because the error was reproducable without X. The symptom is the following: As soon as one tries to kill a TCSH process under Cygwin, this process keeps alive without beeing able to enter any further commands. The TCSH process turns into "I" stated waiting for input (see below). Please see the thread mentioned above to view my cygcheck output. Any hints or bugfixes are very much appreciated!!! Thanks a lot in advance! Best regards BSE --- Weitergeleitete Nachricht / Forwarded Message --- Date: Thu, 17 Jun 2004 17:54:27 -0400 (EDT) From: Igor Pechtchanski To: cygwin-xfree AT cygwin DOT com Subject: Re: Cannot close XTERM with ALT+F4 when using TCSH On Thu, 17 Jun 2004, "Else Böse" wrote: > ... snip ... > > > So it lets you close the window, and the tcsh process doesn't linger on? > > Mmmmh, seems not to be the case. I just checked my process list and saw lots > of "I" marked processes, e.g. > > I 504 1 504 4012 15 11369 22:41:02 /usr/bin/tcsh Else, The "I" is normal - it just means that the process is in the "waiting for input" state. You'll see it also on bash and sh processes that aren't the current shell. What's not normal is the fact that the process doesn't have a parent, and is left over after rxvt closes (this, BTW, may also be a bug in rxvt). > This one remained after I closed my last rxvt. > What does this mean? > > > > > The next is to try attaching to tcsh with a debugger and seeing if it > > > > gets any signals from the xterm as it gets closed (it should get at > > > > least a SIGHUP). > > > > > > Good idea! > > > I also thought that it must have to do with this, at least from > > > looking at the strace output after doing ALT+F4 : > > > > > > 43394846 44791043 [main] xterm 4000 kill_pgrp: pid 3824, signal 1 > > > 1670 44792713 [main] xterm 4000 kill_pgrp: killing pid 3824, pgrp 3824, p->ctty 16, myself->ctty 0 > > > 58 44792771 [main] xterm 4000 sig_send: sendsig 0x524, pid 3824, signal 1, its_me 0 > > > 31 44792802 [main] xterm 4000 sig_send: Not waiting for sigcomplete. its_me 0 signal 1 > > > 15466960 43593591 [sig] -csh 3824 sigpacket::process: signal 1 processing > > > 58 43593649 [sig] -csh 3824 sigpacket::process: signal 1 blocked > > > 18 43593667 [sig] -csh 3824 sigpacket::process: returning -1 > > > 121 44792923 [main] xterm 4000 sig_send: returning 0x0 from sending signal 1 > > > > > > From this it seems that tcsh does not accept signal 1 (SIGHUP). > > > Any ideas why? > > > > Nope. But the same signal should have been sent from both rxvt and a > > console window (if you run tcsh in those). One thing to do would be to > > strace both of those, and compare the relevant chunks of the output. > > > > > Thanks for any further hints. > > > > > > BSE > > > > Another thing I thought of is trying to send the signal to tcsh > > explicitly, using the "kill -1" command. See if that works, and if it > > does, see how the strace output differs. > > Here comes the strace using kill -1 > > 45779212 55756681 [sig] -csh 5064 sigpacket::process: signal 1 processing > 87 55756768 [sig] -csh 5064 sigpacket::process: signal 1 blocked > 18 55756786 [sig] -csh 5064 sigpacket::process: returning -1 > 58 55756844 [sig] -csh 5064 sigpacket::process: signal 19 processing > 35 55756879 [sig] -csh 5064 sigpacket::process: default signal 19 ignored > 17 55756896 [sig] -csh 5064 sigpacket::process: returning 1 > > Looks pretty similar to the above, or? > Seems you're right. It has to do with tcsh not accepting SIGHUPs. I think we can reliably reproduce this, and it's independent of any X applications (i.e., I've reproduced this on my machine with a tcsh running in a console window, and sending it a SIGHUP). > But how could I change this? > I looked into /etc/csh.login and /etc/csh.cshrc and removed also my > ~/.cshrc. No evidence except that in /etc/csh.cshrc the interrupts are > disabled by default using 'onintr -'. I removed that but have still the same > problem. > > Further ideas? Well, now that it's reproducible outside of X, you should probably report this on the main Cygwin list as a tcsh problem (I'd make it a full initial report, with an attached cygcheck output, etc, although you can refer to this thread in the archives[*]). FWIW, I seem to recall that tcsh worked fine for me in the past (I'm a bash user, so I wouldn't have noticed this problem). It may be a bug in tcsh that manifested with the new Cygwin DLL, or a bug in the new version of Cygwin. If you're willing to help the maintainer out and do some debugging, you could try to build tcsh from source and debug info. Good luck! Igor [*] -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton -- +++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++ GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/