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