* Re: Terminal problem with linux-2.0.34 [not found] <19990217173737.D29924@niksula.cs.hut.fi> @ 1999-02-17 16:03 ` Peter Stephenson 1999-04-27 21:14 ` [Solved] " Ville Herva 0 siblings, 1 reply; 6+ messages in thread From: Peter Stephenson @ 1999-02-17 16:03 UTC (permalink / raw) To: Ville Herva, Zsh hackers list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Solved] Re: Terminal problem with linux-2.0.34 1999-02-17 16:03 ` Terminal problem with linux-2.0.34 Peter Stephenson @ 1999-04-27 21:14 ` Ville Herva 1999-04-28 7:51 ` Peter Stephenson 0 siblings, 1 reply; 6+ messages in thread From: Ville Herva @ 1999-04-27 21:14 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list; +Cc: sak 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Solved] Re: Terminal problem with linux-2.0.34 1999-04-27 21:14 ` [Solved] " Ville Herva @ 1999-04-28 7:51 ` Peter Stephenson 0 siblings, 0 replies; 6+ messages in thread From: Peter Stephenson @ 1999-04-28 7:51 UTC (permalink / raw) To: Ville Herva, Zsh hackers list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <199902151522.KAA06190@po_box.cig.mot.com>]
* Re: Terminal problem with linux-2.0.34 [not found] <199902151522.KAA06190@po_box.cig.mot.com> @ 1999-02-15 16:02 ` Peter Stephenson 0 siblings, 0 replies; 6+ messages in thread From: Peter Stephenson @ 1999-02-15 16:02 UTC (permalink / raw) To: Zsh hackers list "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <19990214112653.A22618@turing.netspan.fi>]
* Re: Terminal problem with linux-2.0.34 [not found] <19990214112653.A22618@turing.netspan.fi> @ 1999-02-15 9:58 ` Peter Stephenson 1999-02-15 10:57 ` Ville Herva 0 siblings, 1 reply; 6+ messages in thread From: Peter Stephenson @ 1999-02-15 9:58 UTC (permalink / raw) To: vherva, Zsh hackers list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Terminal problem with linux-2.0.34 1999-02-15 9:58 ` Peter Stephenson @ 1999-02-15 10:57 ` Ville Herva 0 siblings, 0 replies; 6+ messages in thread From: Ville Herva @ 1999-02-15 10:57 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers, Samuli Kärkkäinen 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-04-28 8:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <19990217173737.D29924@niksula.cs.hut.fi> 1999-02-17 16:03 ` Terminal problem with linux-2.0.34 Peter Stephenson 1999-04-27 21:14 ` [Solved] " Ville Herva 1999-04-28 7:51 ` Peter Stephenson [not found] <199902151522.KAA06190@po_box.cig.mot.com> 1999-02-15 16:02 ` Peter Stephenson [not found] <19990214112653.A22618@turing.netspan.fi> 1999-02-15 9:58 ` Peter Stephenson 1999-02-15 10:57 ` Ville Herva
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).