Date: Mon, 02 Sep 2002 11:29:28 +0900 From: TOMITA Yoshinori <yoshint@flab.fujitsu.co.jp> To: Martin Kraemer <Martin.Kraemer@Fujitsu-Siemens.com> Cc: FreeBSD-stable@FreeBSD.ORG, tcsh@mx.gw.com Subject: Re: Strange bug: tcsh stops reading .tcshrc after 4kB Message-ID: <ywlwuq5gm47.fsf@cerberus.proc.flab.fujitsu.co.jp> In-Reply-To: <20020829111414.A54912@deejai2.mch.fsc.net> (Martin Kraemer's message of "Thu, 29 Aug 2002 11:14:14 %2B0200") References: <20020829111414.A54912@deejai2.mch.fsc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Martin.
>> On Thu, 29 Aug 2002 11:14:14 +0200, Martin Kraemer
>> <Martin.Kraemer@Fujitsu-Siemens.com> said:
Ma> On FreeBSD (I assume this is related to the bug) I "often"
Ma> experience a very strange bug which was not there in the past.
Ma> It manifests by tcsh not finishing reading all of .tcshrc (or/and
Ma> .login).
Ma> Especially strange is the fact that it does not always happen, but
Ma> only when tcsh is started from the x11 window manager directly,
Ma> not (or at least, not always) when started from another tcsh. The
Ma> exact trigger is still unknown to me.
I also experienced the very similar problem after cvsup around 2002-08-22,
on both 4.6-STABLE and 5-CURRENT.
=46rom my quick investigation, I found that the trigger was "unset"
command in ~/.cshrc. And I guess that NLS catalogues are something to
do with this problem.
I checked with ktrace output and tcsh-6.12.00 source files.
1. open tcsh.cat. file descriptor is 3
62220 tcsh CALL open(0xbfbfd590,0,0x1b6)
62220 tcsh NAMI "/usr/local/share/nls/C/tcsh.cat"
62220 tcsh RET open 3
....
2. sh.misc.c:closem()
file descriptor 0-63(except some) are closed.
62220 tcsh CALL close(0)
62220 tcsh RET close 0
62220 tcsh CALL close(0x1)
62220 tcsh RET close 0
*** FD 3, which is bounded to tcsh.cat, is also closed here.
3. open ~/.cshrc, file descriptor is 3
62220 tcsh NAMI "/root/.cshrc"
62220 tcsh RET open 0
62220 tcsh CALL dup(0)
62220 tcsh RET dup 1
62220 tcsh CALL dup(0x1)
62220 tcsh RET dup 2
62220 tcsh CALL dup(0x2)
62220 tcsh RET dup 3
62220 tcsh CALL close(0x2)
62220 tcsh RET close 0
62220 tcsh CALL close(0x1)
62220 tcsh RET close 0
62220 tcsh CALL close(0)
62220 tcsh RET close 0
62220 tcsh CALL fcntl(0x3,0x2,0x1)
62220 tcsh RET fcntl 0
...
4. read 4096 bytes from .cshrc
62220 tcsh CALL read(0x3,0xbfbfc83c,0x1000)
62220 tcsh GIO fd 3 read 4096 bytes
5. evaluate "unset" command in ~/.cshrc
6. In sh.set.c:unset(), "catclose(catd)" will close FD 3, which
is bounded to ~/.cshrc !!!
62220 tcsh CALL close(0x3)
62220 tcsh RET close 0
7. open tcsh.cat again
62220 tcsh CALL open(0xbfbfb150,0,0x1b6)
62220 tcsh NAMI "/usr/local/share/nls/C/tcsh.cat"
62220 tcsh RET open 3
8. When 4096-byte buffer of ~/.cshrc becomes empty, tcsh will read
from FD 3 for the rest of ~/.cshrc.
But you cannot read ~/.cshrc any more.
62220 tcsh CALL read(0x3,0xbfbfa7bc,0x1000)
62220 tcsh GIO fd 3 read 0 bytes
""
62220 tcsh RET read 0
My nasty workaround is to comment out the two lines in sh.set.c:
(void) catclose(catd);
nlsinit();
--=20
TOMITA Yoshinori
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ywlwuq5gm47.fsf>