* 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; 3+ 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] 3+ 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; 3+ 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] 3+ 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; 3+ 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] 3+ messages in thread
end of thread, other threads:[~1999-04-28 8:16 UTC | newest] Thread overview: 3+ 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
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).