Re: Terminal problem with linux-2.0.34

Re: Terminal problem with linux-2.0.34

[Peter Stephenson]

Ville Herva wrote:
> Today, I came across a very interesting problem with tha same linux
> machine: the clock() function would always return -1!

clock() isn't used directly in 3.1.5, but times(), which is closely
related, is used.  You can see if the bug shows up there just by typing
`times' (plus two returns :-(), which would typically report a few seconds'
usage.  However, it doesn't look like it should be crucial, though if
there's a kernel bug around, all bets are off.

If system calls are tickling a deeper problem, then apart from times() the
other chief suspect might be getrlimit(), because of its association with
times for processes, though times() is more likely.  A brief trial on
2.0.32 suggests neither /bin/bash (1.14.7(1)) nor /bin/tcsh (6.07.02) use
times() in their initialisation, and only call getrlimit() for
RLIMIT_NOFILE (bash) or only when told to (tcsh) --- zsh calls times()
after every command and reads all the limits when starting.  If you feel
interested enough to comment out all the calls to times(), that should be
harmless enough in terms of side effects.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

[Solved] Re: Terminal problem with linux-2.0.34

[Ville Herva]

On Wed, Feb 17, 1999 at 05:03:02PM +0100, you [Peter Stephenson] claimed:
> Ville Herva wrote:
> > Today, I came across a very interesting problem with tha same linux
> > machine: the clock() function would always return -1!
>
> clock() isn't used directly in 3.1.5, but times(), which is closely
> related, is used.  You can see if the bug shows up there just by typing
> `times' (plus two returns :-(), which would typically report a few seconds'
> usage.  However, it doesn't look like it should be crucial, though if
> there's a kernel bug around, all bets are off.
>
> If system calls are tickling a deeper problem, then apart from times() the
> other chief suspect might be getrlimit(), because of its association with
> times for processes, though times() is more likely.  A brief trial on
> 2.0.32 suggests neither /bin/bash (1.14.7(1)) nor /bin/tcsh (6.07.02) use
> times() in their initialisation, and only call getrlimit() for
> RLIMIT_NOFILE (bash) or only when told to (tcsh) --- zsh calls times()
> after every command and reads all the limits when starting.  If you feel
> interested enough to comment out all the calls to times(), that should be
> harmless enough in terms of side effects.

After finding that interesting feature of clock() (that was fixed by
the glibc maintainers), I had a rather long period of not paying
attention to this.

Then, somebody who had similar problems, pointed me that a select() call
had a rather weird timeout value in the starce output:

> select(11, [10], NULL, NULL, {20976515, 300}) = 1 (in [10], left
> {20976512, 870000})

This proved to be the select call in line 517 in Zle/zle_main.c (zsh-3.1.5
vanilla):       
                
                if (!kungetct && select(SHTTY+1, (SELECT_ARG_2_T) & foofd,
                                        NULL, NULL, &tv) <= 0)

If I add the following line before the above call, zsh works well:
                
                tv.tv_sec = 0;

As far as I an see, this not a but in zsh. As we know, on Linux, select()
modifies the tv struct to reflect the time not spend waiting for io. (If
the time limit is, say, 5 secs and select() uses 2, it changes the tv
value to 3). Now, zsh_main.c does reinitialize tv.tv_usec before each
call. It only initializes tv.tv_sec to zero once, which is sane, because
select() should only decrement the value. After 248 days of uptime select
seems to begin poking some weird values (like 13126839) to the tv.tv_sec
variable. It is not obvious to me at the first glance where in the kernel
the bug is, but I'll try to find it.

The linux select man page does say

        "Consider timeout to be undefined after select returns."

so perhaps this is well defined behaviour ;). Anyway, the mentioned fix
should not break anything, so you may want to merge that.



-- v --

v@iki.fi

Re: [Solved] Re: Terminal problem with linux-2.0.34

[Peter Stephenson]

Ville Herva wrote:
> This proved to be the select call in line 517 in Zle/zle_main.c (zsh-3.1.5
> vanilla):       
>                 
>                 if (!kungetct && select(SHTTY+1, (SELECT_ARG_2_T) & foofd,
>                                         NULL, NULL, &tv) <= 0)
> 
> If I add the following line before the above call, zsh works well:
>                 
>                 tv.tv_sec = 0;

Thanks, this is the diff for 3.1.5-pws-16 (Bart's already put something into
3.0.6).

--- Src/Zle/zle_main.c.tv	Mon Apr 19 11:40:09 1999
+++ Src/Zle/zle_main.c	Wed Apr 28 09:48:30 1999
@@ -413,7 +413,6 @@
 
     baud = getiparam("BAUD");
     costmult = (baud) ? 3840000L / baud : 0;
-    tv.tv_sec = 0;
 #endif
 
     /* ZLE doesn't currently work recursively.  This is needed in case a *
@@ -523,6 +522,7 @@
 #ifdef HAVE_SELECT
 	    if (baud && !(lastcmd & ZLE_MENUCMP)) {
 		FD_SET(SHTTY, &foofd);
+		tv.tv_sec = 0;
 		if ((tv.tv_usec = cost * costmult) > 500000)
 		    tv.tv_usec = 500000;
 		if (!kungetct && select(SHTTY+1, (SELECT_ARG_2_T) & foofd,

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Terminal problem with linux-2.0.34

[Peter Stephenson]

"Larry P . Schrof" wrote:
> - Any time the user runs a program that makes a stat() call, the
> shell hangs forever, until the user breaks out of it. Even after sending
> the process, say ls -l, a signal, it takes awhile to get the shell prompt
> back.

Something this weird suggests zsh is tickling something in Linux, and also
suggests the only way to find out what is just painfully to comment bits of
code out until it goes away; it's probably not just zle.  (Does the stat()
problem go away if you run zsh without zle?)

I have access to a 2.0.32 system --- unfortunately it needs booting too
often to show this problem --- with zsh 3.0.2 and looking at strace I can
only suggest checking things like

- setlocale()
- getuid(), geteuid(), and friends
- isatty()
- tcsetpgrp() and related terminal handling
- getrlimit() --- if this gets a wrong type for a limit, and passes it on,
  that could cause fireworks, though why after 250 days uptime?
- termcap

I can pass on what strace is giving here for comparison, if that's any
use.

Also, it would be worth making sure it isn't in the latest development
version
http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-8.tar.gz
since the stuff that opens the terminal has changed a bit.

I doubt if this is helpful.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Terminal problem with linux-2.0.34

[Ville Herva]

On Mon, Feb 15, 1999 at 10:58:23AM +0100, you [Peter Stephenson] claimed:
> vherva@turing.netspan.fi wrote:
> > The flaw in the terminal handling appears as follows: when I type text
> > on the command line, only the first two characters are echoed. The line
> > does show up, if erase a character. Also, the command line is only
> > executed after I press return twice.
> 
> Is that the first two characters including the prompt, or after the prompt?
> Might help tell if it's really in the zsh code or maybe a bug in a tty
> driver.

That's two chars after the prompt - although I occasionally get three or
four.

> It looks like it may be impossible to track down remotely, but here are
> some other things you could jiggle to see; they are just random counsels of
> despair, really.
> 
> 1. Try setting TERM to something different (e.g. vt100)

I've tried atleast xterm, xterm-color and vt100 and ansi. The problem
appears with all of them.

> 2. Try resetting the terminal before each line, for example
>   precmd() { reset; }    or    precmd() { tset; }
> depending what you have available.

That had no effect either.

> 3. Try running `script' and looking to see if there's anything funny in the
> transcript of a short session.  Chances are there isn't, since the problem
> with `return' suggests it's not just on output.  In particular, does
> deleting (which you say brings the line back) show up as anything more than
> a ^H ?  

Pressing backspace does not bring the line back (it seems to invisibly
delete the char backwards, though), but if I move backwards with left
arrow and press ctrl-d, the line gets echoed and the character is erased
as it should be.

> Also, when you need to type two returns to get it to work, do both
> show up in the transcript as ^M or only one?  (If the option promptcr is
> set, you get a second ^M at the beginning of the new prompt anyway.)
> 
> 4. Try recompiling with TTY_NEEDS_DRAINING defined to 1 (you can simply put 
> #define TTY_NEEDS_DRAINING 1
> at the top of zle_main.c since it doesn't seem to appear in the
> configuration stuff.)  Can't see why it should be this, either, but then I
> can't see why it should be anything else.
> 
> 5. If the two characters you do get on the line are after the prompt, maybe
> it's connected with the `clear-to-end-of-line' you get at the end of the
> prompt.  Try setting TERMCAP (if that works on Linux) to:
> xterm|vs100|xterm terminal emulator:\
>         :am:km:mi:ms:xn:bs:pt:\
>         :co#80:li#65:\
>         :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
>         :LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:\
>         :cd=\E[J:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\
>         :cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:ho=\E[H:\
>         :ic=\E[@:k0=\EOy:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
>         :k5=\EOt:k6=\EOu:k7=\EOv:k8=\EOl:k9=\EOw:kb=\b:\
>         :kd=\EOB:ke=\E[?1l:kl=\EOD:kr=\EOC:ks=\E[?1h:ku=\EOA:\
>         :nd=\E[C:r1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H:\
>         :r2=@kf1=\EOP:rc=\E8:sc=\E7:se=\E[m:so=\E[7m:sr=\EM:\
>         :st=\EH:up=\E[A:
> (I've deliberately removed :ce=\E[K: from this.)

I will try script, TTY_NEEDS_DRAINING and the TERMCAP ASAP, I'll report
the result. 

Thanks for the response!


--
Ville Herva       Ville.Herva@netspan.fi   +358-50-5164500
Netspan Oy        netspan@netspan.fi       PL 65  FIN-02151 Espoo
PGP key available: http://www.iki.fi/v/pgp.html

Re: Terminal problem with linux-2.0.34

[Peter Stephenson]

vherva@turing.netspan.fi wrote:
> The flaw in the terminal handling appears as follows: when I type text
> on the command line, only the first two characters are echoed. The line
> does show up, if erase a character. Also, the command line is only
> executed after I press return twice.

Is that the first two characters including the prompt, or after the prompt?
Might help tell if it's really in the zsh code or maybe a bug in a tty
driver.

It looks like it may be impossible to track down remotely, but here are
some other things you could jiggle to see; they are just random counsels of
despair, really.

1. Try setting TERM to something different (e.g. vt100)

2. Try resetting the terminal before each line, for example
  precmd() { reset; }    or    precmd() { tset; }
depending what you have available.

3. Try running `script' and looking to see if there's anything funny in the
transcript of a short session.  Chances are there isn't, since the problem
with `return' suggests it's not just on output.  In particular, does
deleting (which you say brings the line back) show up as anything more than
a ^H ?  Also, when you need to type two returns to get it to work, do both
show up in the transcript as ^M or only one?  (If the option promptcr is
set, you get a second ^M at the beginning of the new prompt anyway.)

4. Try recompiling with TTY_NEEDS_DRAINING defined to 1 (you can simply put 
#define TTY_NEEDS_DRAINING 1
at the top of zle_main.c since it doesn't seem to appear in the
configuration stuff.)  Can't see why it should be this, either, but then I
can't see why it should be anything else.

5. If the two characters you do get on the line are after the prompt, maybe
it's connected with the `clear-to-end-of-line' you get at the end of the
prompt.  Try setting TERMCAP (if that works on Linux) to:
xterm|vs100|xterm terminal emulator:\
        :am:km:mi:ms:xn:bs:pt:\
        :co#80:li#65:\
        :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
        :LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:\
        :cd=\E[J:cl=\E[H\E[2J:cm=\E[%i%d;%dH:\
        :cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:ho=\E[H:\
        :ic=\E[@:k0=\EOy:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
        :k5=\EOt:k6=\EOu:k7=\EOv:k8=\EOl:k9=\EOw:kb=\b:\
        :kd=\EOB:ke=\E[?1l:kl=\EOD:kr=\EOC:ks=\E[?1h:ku=\EOA:\
        :nd=\E[C:r1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H:\
        :r2=@kf1=\EOP:rc=\E8:sc=\E7:se=\E[m:so=\E[7m:sr=\EM:\
        :st=\EH:up=\E[A:
(I've deliberately removed :ce=\E[K: from this.)

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy