Cannot close XTERM with ALT+F4 when using TCSH

Fri Jun 18 10:27:00 GMT 2004

Thanks a lot Igor!!

Just sent out a question to cygwin@cygwin.com.

In the meantime I found out that everything works with my old TCSH version

tcsh 6.12.00 (Astron) 2002-07-23 (i386-intel-posix) options
8b,nls,dl,al,rh,color

Since I'm quite busy at the moment, I need to wait with any further research
until I get a bugfix for the new version.

Thanks and best regards
BSE

> 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
> 

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info