kjt@minnow.sp.unisys.com (Kevin Thomas) (05/31/91)
A bug in the version of csh we are running recently reared its ugly head.
The problem occurs when a csh is started from an application such as vi, and
the .cshrc contains an if/then/endif mismatch. Under these conditions the
csh process prints an error message when it detects the missing endif, but
it then rapidly grows in size. The csh never runs the command as it was asked
to do, and is probably trapped in a recursive loop. Killing the process allows
the application to continue.
The .csh contains lines like the following:
if ($?prompt) then
set ignoreeof
...
The if/then should be terminated with an endif, but it is not. When the
user logs in, the csh doesn't complain at all. This is probably because the
if expression evaluates to true.
If the user enters vi and enters the command ":!ls" the csh prints an error
message about the missing endif, and then goes into the loop described above.
I suppose that vi is attempting something like:
execlp("csh","csh","-c","ls",NULL);
Therefore, the if expression in the .cshrc evaluates to false. Csh must be
trying to skip to the end of the if/then/endif statement, but goes insane.
Our computer is a Unisys 5000/80 running Unix System 5.3. The OS release
number is 6.03.00.
I'd be interested to know how widespread is this problem. If you'd like to
give the above example a try on your OS and mail me the results, I will
summarize for the net.
--
Kevin Thomas kjt@minnow.sp.unisys.com
Unisys Corporation ...!pyramid!pwcs!minnow!kjtiand@labtam.labtam.oz (Ian Donaldson) (06/02/91)
kjt@minnow.sp.unisys.com (Kevin Thomas) writes: >I'd be interested to know how widespread is this problem. If you'd like to >give the above example a try on your OS and mail me the results, I will >summarize for the net. I don't know if this problem is related to the ones I have seen but it probably is. The problem is probably due to an incorrect port of csh using a new C compiler that does automatic register allocation optimization. Csh depends on certain variables NOT being promoted to registers for proper functionality. (ie: longjmp processing depends on it) In short the quick and dirty way to fix this is to tell the C compiler not to promote non-register variables to 'register' when compiling csh. The long and slow way to sort this out is to locate all places that it matters and fix them. I found this same problem with an old Encore SVR3 a few years ago and AT&T SVR4.0 csh. In both cases the same thing happened. If there was an error in your ".cshrc" or ".login" it caused it to go crazy malloc()ing until you ran out of virtual memory. For the Encore case, I compiled up my own 4.3-tahoe csh with register optimization disabled, and for SVR4.0 I recompiled the csh similarly and the problems vanished. I also managed to find one piece of code where I could prevent the bug occuring with register optimization enabled, but I gave up after a long while looking for the others... its not worth the time to me. Ian D