zsh hangs on IRIX 5.2

zsh hangs on IRIX 5.2

[Achim Braemer]

Hello zsh experts:

I am experiencing strange zsh behaviour on IRIX 5.2 with zsh
2.6-beta13. It has been there a long time, I don't know exactly how
long.

When a user logs in to the local the system using rlogin (with zsh as
login shell, of course), and for some reason the session crashes
(typically because the remote process is beeng killed because of idle
time) then the local zsh process hangs and consumes 99% CPU time.

The behaviour is not 100% reproducible, to me it seems that it happens
maybe 20% of the time. 

This does not happen with sh, ksh or csh as login shell, but I am still
not quite sure whether it's really zsh's foult or rather an IRIX bug.

Any help would be greatly appreciated, because the problem occurs quite
often on my system blocking useful work!

-- Cheers, Achim --


PS: I do have problems with other programs hangin occasionaly. The
gnuserver process for emacs client/server editing is one such example. I
don't know if this has anything to do with the first problem, just
thought I'd mention it.

------------------------------------------------------------------------
 Achim Braemer              braemer@doc.physi.uni-heidelberg.de
 Physikalisches Institut    http://doc.physi.uni-heidelberg.de/~braemer
 Philosophenweg 12          Telephone: 06221 / 549370  Fax: 475733
 D-69120 Heidelberg         From DESY dial direct 6-207-9370
------------------------------------------------------------------------

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[leibniz!stucki]

I see the same behavior as he does in two other Systems:

Quoting Achim Braemer :
> 
> I am experiencing strange zsh behavior on IRIX 5.2 with zsh
> 2.6-beta13. It has been there a long time, I don't know exactly how
> long.
At least the last two years, I complained about this shortly after
we installed our first zsh.

> When a user logs in to the local the system using rlogin (with zsh as
> login shell, of course), and for some reason the session crashes
> (typically because the remote process is being killed because of idle
> time) then the local zsh process hangs and consumes 99% CPU time.
exactly the same here, except it's not necessary to have zsh for
login-shell (see below).

> This does not happen with sh, ksh or csh as login shell, but I am still
> not quite sure whether it's really zsh's fault or rather an IRIX bug.
It IS some zsh-bug, but it's a strange one ...

> Any help would be greatly appreciated, because the problem occurs quite
> often on my system blocking useful work!
It even kills a whole machine overnight, by blocking all usable CPU cycles
and this way crowding a machine with cron-jobs 'til it 'breaks'.


Well, we traced/debugged a bit and found out:
- it does NOT happen if you 'unset ignoreeof'
  ( so zsh is 'simply' ignoring an eof-condition FOREVER )

- if you hit TEN  '^D' (eof) on the keyboard zsh goes away
  ( even with ignoreeof set , so THERE is a maximum )

- a zsh which idles (waits for the keyboard/tty) goes away
  when the Window/Modem-Connection dies

- BUT a zsh WAITING FOR A PROCESS TO COMPLETE,
  RUNS FOREVER READING 'nothing' FROM STDIN
  IF THE SUBPROCESS VANISHES AND
  ZSH WAKES UP ON A 'DEAD' TTY.

May be this helps ?

We too (at math.fu-berlin.de) would GREATLY APPRECIATE ANYTHING which
allows to safely set ignoreeof !

Stucki

   **v**   ----v-----------------------------------------------------------
    S    *    |   Christoph von Stuckrad      | <stucki@math.fu-berlin.de> \
    t   /  *  |   Dahlem                      | ...!unido!fub!leibniz!stucki|
    u /     * |   Fachbereich Mathematik, EDV | Tel:+49 30 838-754{9|8}     |
<stucki>- - C |   Freie Universitaet Berlin   | Fax:+49 30 838-5913         |
    k \     * |   Arnimallee 2-6              | IRC: /nick stucki           |
    r   \  *  | D-14195 Berlin                | PGP: not yet certified :-(  |
    a    *    |   Germany                     |      ask for key by mail   /
  **d**   ----^-----------------------------------------------------------

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Peter Stephenson]

leibniz!stucki@leibniz.math.fu-berlin.de wrote:
> - BUT a zsh WAITING FOR A PROCESS TO COMPLETE,
>   RUNS FOREVER READING 'nothing' FROM STDIN
>   IF THE SUBPROCESS VANISHES AND
>   ZSH WAKES UP ON A 'DEAD' TTY.

I've been trying to reproduce this on our IRIX systems but have so far
failed; presumably there's another ingredient I haven't found (I can't
believe zsh's in Dahlem can be *that* different to those in Zeuthen,
or do we have to wait for Berlin-Brandenburg? -:)).

If you enter a sleep command and type more than 20 ^D's while you're
waiting for it to finish, the shell exits, as I would expect given the
current code.  Something funny must be happening when the tty goes
away which I don't understand.  The only things I can think of are (1)
that read() is returning `real' ^D's instead of simply a 0 from read,
which is very unlikely, or (2) that zle is not being used and the
error is somewhere else.  Here's the relevant code from the line
editor, in getkey(), zle_main.c, if anyone can think of anything.
It's been like this for some time.

(N.B.: the 20 maximum here is for ^D's typed while zsh wasn't looking
at input.  The 10 maximum applies if it was; the counter for that is
back in the main loop.)

You can at least see if this is the problem by removing the
`if (isset(IGNOREEOF)...) continue' and seeing if the problem goes
away.  That will have the side-effect that a ^D in typeahead will
cause the shell to exit.


while ((r = read(SHTTY, &cc, 1)) != 1) {
    if (r == 0) {
	/* The test for IGNOREEOF was added to make zsh ignore ^Ds
	   that were typed while commands are running.  Unfortuantely
	   this caused trouble under at least one system (SunOS 4.1).
	   Here shells that lost their xterm (e.g. if it was killed
	   with -9) didn't fail to read from the terminal but instead
	   happily continued to read EOFs, so that the above read
	   returned with 0, and, with IGNOREEOF set, this caused
	   an infinite loop.  The simple way around this was to add
	   the counter (icnt) so that this happens 20 times and than
	   the shell gives up (yes, this is a bit dirty...). */
	if (isset(IGNOREEOF) && icnt++ < 20)
	    continue;
	stopmsg = 1;
	zexit(1);
    }
    icnt = 0;
    if (errno == EINTR) {
	die = 0;
	if (!errflag)
	    continue;
	errflag = 0;
	errno = old_errno;
	return EOF;
    } else if (errno == EWOULDBLOCK) {
	fcntl(0, F_SETFL, 0);
    } else if (errno == EIO && !die) {
	ret = jobbingv;
	jobbingv = OPT_SET;
	attachtty(mypgrp);
	refresh();	/* kludge! */
	jobbingv = ret;
	die = 1;
    } else if (errno != 0) {
	zerr("error on TTY read: %e", NULL, errno);
	stopmsg = 1;
	zexit(1);
    }
}

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Achim Braemer]

I have put a few printf's in the code and found out that the endless
loop of zsh does not occur in the quotes piece of code from zle_main.c.
It must be somewhere else, but I have no clue of where to look.
Perhaps a signal handling problem?

-- Achim --



Peter Stephenson writes on March 25:
 > leibniz!stucki@leibniz.math.fu-berlin.de wrote:
 > > - BUT a zsh WAITING FOR A PROCESS TO COMPLETE,
 > >   RUNS FOREVER READING 'nothing' FROM STDIN
 > >   IF THE SUBPROCESS VANISHES AND
 > >   ZSH WAKES UP ON A 'DEAD' TTY.
 > 
 > You can at least see if this is the problem by removing the
 > `if (isset(IGNOREEOF)...) continue' and seeing if the problem goes
 > away.  That will have the side-effect that a ^D in typeahead will
 > cause the shell to exit.
 > 
 > [part from zle_main.c]
 > while ((r = read(SHTTY, &cc, 1)) != 1) {  
 >     if (r == 0) {
 > 	/* The test for IGNOREEOF was added to make zsh ignore ^Ds
 > 	   that were typed while commands are running.  Unfortuantely
 > 	   this caused trouble under at least one system (SunOS 4.1).
 > 	   Here shells that lost their xterm (e.g. if it was killed
 > 	   with -9) didn't fail to read from the terminal but instead
 > 	   happily continued to read EOFs, so that the above read
 > 	   returned with 0, and, with IGNOREEOF set, this caused
 > 	   an infinite loop.  The simple way around this was to add
 > 	   the counter (icnt) so that this happens 20 times and than
 > 	   the shell gives up (yes, this is a bit dirty...). */
 > 	if (isset(IGNOREEOF) && icnt++ < 20)
 > 	    continue;
 > 	stopmsg = 1;
 > 	zexit(1);
 >     }
[...]

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Bas V. de Bakker]

Achim Braemer <braemer@doc.physi.uni-heidelberg.de> writes:

> I have put a few printf's in the code and found out that the endless
> loop of zsh does not occur in the quotes piece of code from
> zle_main.c.  It must be somewhere else, but I have no clue of where
> to look.  Perhaps a signal handling problem?

Surely it shouldn't be a problem to find out where a program loops?
That's what debuggers are for.  Have you tried "gdb zsh <pid>"?

Bas.

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Achim Braemer]

Bas V. de Bakker writes on March 26:
 > Surely it shouldn't be a problem to find out where a program loops?
 > That's what debuggers are for.  Have you tried "gdb zsh <pid>"?

Thank you very much, I really didn't know of this possibility.

I used dbx and found out that the loop occurs in utils.c:


/* give the tty to some process */

/**/
void
attachtty(pid_t pgrp)
{
    static int ep = 0;

    if (jobbing) {
#ifdef HAVE_TCSETPGRP
        if (SHTTY != -1 && tcsetpgrp(SHTTY, pgrp) == -1 && !ep)
#else
# if ardent
        if (SHTTY != -1 && setpgrp() == -1 && !ep)
# else
        int arg = pgrp;

        if (SHTTY != -1 && ioctl(SHTTY, TIOCSPGRP, &arg) == -1 && !ep)
# endif
#endif
        {
            if (kill(pgrp, 0) == -1)
                attachtty(mypgrp);                     <===============
            else {
                zerr("can't set tty pgrp: %e", NULL, errno);
                fflush(stderr);
                opts[MONITOR] = OPT_UNSET;
                ep = 1;
                errflag = 0;
            }
        }
    }
}


I marked the line that I find suspicious. After I simply commented out
this line the hangups didn't occur anymore.

Does that help the experts to figure out the problem? Please tell me if
you need more information. And thanks for the help!

-- Achim --

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Zefram]

>/**/
>void
>attachtty(pid_t pgrp)
>{
...
>        {
>            if (kill(pgrp, 0) == -1)
>                attachtty(mypgrp);                     <===============
>            else {
...

The obvious solution is to add a flag so that this only retries once.
But in which circumstances is this retry needed at all?

-zefram

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Barton E. Schaefer]

On Mar 26,  6:45pm, Zefram wrote:
} Subject: Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)
}
} >/**/
} >void
} >attachtty(pid_t pgrp)
} >{
} ...
} >        {
} >            if (kill(pgrp, 0) == -1)
} >                attachtty(mypgrp);                     <===============
} >            else {
} ...
} 
} The obvious solution is to add a flag so that this only retries once.
} But in which circumstances is this retry needed at all?

I think this is what is wanted:

		if (pgrp != mypgrp && kill(pgrp, 0) == -1)
		    attachtty(mypgrp);
		else {

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Peter Stephenson]

schaefer@z-code.ncd.com wrote:
> I think this is what is wanted:
> 
> 		if (pgrp != mypgrp && kill(pgrp, 0) == -1)
> 		    attachtty(mypgrp);
> 		else {

That's got to work, since it'll only try the attachtty(mypgrp) once
and then fail.  Here's that as a patch for everyone to try at home.

*** Src/utils.c.pgrp	Wed Mar 27 09:17:42 1996
--- Src/utils.c	Wed Mar 27 09:17:09 1996
***************
*** 2597,2603 ****
  # endif
  #endif
  	{
! 	    if (kill(pgrp, 0) == -1)
  		attachtty(mypgrp);
  	    else {
  		zerr("can't set tty pgrp: %e", NULL, errno);
--- 2597,2603 ----
  # endif
  #endif
  	{
! 	    if (pgrp != mypgrp && kill(pgrp, 0) == -1)
  		attachtty(mypgrp);
  	    else {
  		zerr("can't set tty pgrp: %e", NULL, errno);

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Achim Braemer]

Peter Stephenson writes on March 27:
 > That's got to work, since it'll only try the attachtty(mypgrp) once
 > and then fail.  Here's that as a patch for everyone to try at home.
...

This patch solves the problem on my IRIX 5.2 system. So far I have had
no misbehaviour due to the patch.

I hope this is also true for the problems that Stucki reported for
SunOS4.1.3 + Solaris 2.4.

Thanks a lot to all who helped!

-- Achim --


------------------------------------------------------------------------
 Achim Braemer              braemer@doc.physi.uni-heidelberg.de
 Physikalisches Institut    http://doc.physi.uni-heidelberg.de/~braemer
 Philosophenweg 12          Telephone: 06221 / 549370  Fax: 475733
 D-69120 Heidelberg         From DESY dial direct 6-207-9370
------------------------------------------------------------------------

Re: zsh hangs on IRIX 5.2 / me to: (SunOS4.1.3 + Solaris 2.4)

[Achim Braemer]

Chr. von Stuckrad writes on March 22:
 > 
 > Well, we traced/debugged a bit and found out:
 > - it does NOT happen if you 'unset ignoreeof'
 >   ( so zsh is 'simply' ignoring an eof-condition FOREVER )

This is not the case on IRIX 5.2. I tried to 'unsetopt ignoreeof' but
the hangup still occurs.

 > - a zsh which idles (waits for the keyboard/tty) goes away
 >   when the Window/Modem-Connection dies
 > 
 > - BUT a zsh WAITING FOR A PROCESS TO COMPLETE,
 >   RUNS FOREVER READING 'nothing' FROM STDIN
 >   IF THE SUBPROCESS VANISHES AND
 >   ZSH WAKES UP ON A 'DEAD' TTY.

Yes, here too.

-- Achim --