PLEASE HELP: TCSH does exit when sending SIGHUP

[bse2000 at gmx dot de]

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 <pechtcha@cs.nyu.edu>
To: cygwin-xfree@cygwin.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://cygwin.com/ml/cygwin-xfree/2004-06/msg00142.html>
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/