From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-2164-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 4451 invoked from network); 17 Feb 1999 15:39:17 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 17 Feb 1999 15:39:17 -0000
Received: (qmail 14124 invoked by alias); 17 Feb 1999 15:37:44 -0000
Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 2164
Received: (qmail 14109 invoked from network); 17 Feb 1999 15:37:42 -0000
Message-ID: <19990217173737.D29924@niksula.cs.hut.fi>
Date: Wed, 17 Feb 1999 17:37:37 +0200
From: Ville Herva <vherva@niksula.hut.fi>
To: zsh-users@sunsite.auc.dk
Cc: sak@iki.fi
Subject: Re: Terminal problem with linux-2.0.34
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i


First off, I just noticed that although the problem appears with 3.1.5 and
zsh-3.1.5-pws-8, it is a bit different (better) compared to 3.0.5: 
everything I type gets echoed just fine, but pressing backspace works only
once, after that, the edits won't be echoed. Also moving on the command
line with arrow keys loses the cursor. To execute the command line, two
returns are needed. 

> Peter Stephenson <pws@ibmth.df.unipi.it> wrote:
>
> "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?)

Today, I came across a very interesting problem with tha same linux
machine: the clock() function would always return -1! A little
sample prog:

vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>cat ../../c.c
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]) 
{
   int i;
   int timer = clock();
   for (i = 1000000; i; i--);  
   printf("timer: %i\nclock(): %i\nCLK_TCK: %i\n"
          "CLOCKS_PER_SEC: %i\n%3.2f 3.2f secs.\n", 
          timer, clock(), CLK_TCK, CLOCKS_PER_SEC,
          (float)(clock() - timer) / (float)CLK_TCK / 10000.0,
          (float)(clock() - timer) / (float)CLOCKS_PER_SEC);

   return 1;
}
vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>gcc ../../c.c -o ../../c
vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>../../c
timer: -1
clock(): -1
CLK_TCK: 100
CLOCKS_PER_SEC: 1000000
0.00 3.2f secs.

Now, making little heuristic guess I figured that

vherva@turing:/home/vherva/zsh-3.1.5-pws-8/Src>perl -e '$CLK_TCK = 100;
print 2**31 / $CLK_TCK / 60 / 60 / 24, " days\n"'
248.551348148148 days

which is quite accurately the uptime, zsh became not to work.

This, of course won't explain why zsh messes the command line, while other
shells do not. Is clock() or any similar function used in zle? (There is a
possibility that other timing functions fail, also - it seems that a
counter in the kernel has wrapped around, and libc goes nuts, or something
like that.)

Also, this might explain the other problems Larry Schrof had.

I'll be forwarding this problem to linux-kernel list.

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

Zsh-3.1.5-pws-8 seems to behave exactly like zsh-3.1.5.
 

-- v --

v@iki.fi