mayer@rocksanne.UUCP (Jim Mayer) (07/16/87)
I have been having the following, rather bizzare, problem with the 4.3bsd
C compiler. I get non repeatable compiler errors! By non repeatable I
mean that if I reissue the same command, I will get a different error
or a successful compile. The errors are usually of the form:
compiler error in lib/ccom
or
compiler error: couldn't find basic type 14 (or 4, or 10) for FOO
The behavior is rather bursty; sometimes it goes away, and sometimes it makes
it almost impossible to get any work done. When the compiler completes
successfully it always seems to produce a good object file.
What really puzzles me is the non repeatable behavior of the problem. I took
a brief look through the sources, and didn't find any obvious causes of
non repeatable behavior (calls to "time", "gettimeofday"; writes to temp files
that do not include the current pid, etc.). It could be a file system or hardware
problem, but fsck seems to run fine. Also, I recall having similar problems on
other UNIX machines (4.2 I believe) but never this frequently.
Has anybody else had this problem? Do poltergeists really exist?
-- Jim
--
(Grapevine) mayer.wbst (Arpa) mayer.wbst@Xerox.com
(NS) mayer:wbst128:xerox (Phone) (716) 422-9407
(UUCP) {seismo|allegra}!rochester!rocksanne!mayerron@argus.UUCP (Ron DeBlock) (07/19/87)
In article <328@rocksanne.UUCP>, mayer@rocksanne.UUCP (Jim Mayer) writes: > I have been having the following, rather bizzare, problem with the 4.3bsd > C compiler. I get non repeatable compiler errors! By non repeatable I > mean that if I reissue the same command, I will get a different error > or a successful compile. The errors are usually of the form: > > compiler error in lib/ccom > or > compiler error: couldn't find basic type 14 (or 4, or 10) for FOO > > > Has anybody else had this problem? Do poltergeists really exist? Yes, on a 3B15 running sVr2.1.1. We usually get complaints from the assembler, and recompiling works just fine. I believe we have a bad block somewhere on the disk which occasionally is used in a temp file. I have been unable to verify that, as fsck reports no problems. There is another symptom possibly caused by the same problem: "leaky" pipes. By leaky, I mean typing something like: who | sort and getting someones C source code for output or nothing at all. This is also intermittant. > > -- Jim -- Ron DeBlock KA2IKT uucp: ...!siesmo!rugters!galaxy!andromeda!argus!ron
jsalmi@cs.D.UMN.EDU (John Salmi) (07/20/87)
In article <328@rocksanne.UUCP> mayer@rocksanne.UUCP (Jim Mayer) writes: >I have been having the following, rather bizzare, problem with the 4.3bsd >C compiler. I get non repeatable compiler errors! By non repeatable I >mean that if I reissue the same command, I will get a different error >or a successful compile. The errors are usually of the form: > > compiler error in lib/ccom >or > compiler error: couldn't find basic type 14 (or 4, or 10) for FOO > >Has anybody else had this problem? Do poltergeists really exist? > >-- Jim I have experienced similar compiler errors on our sun 2/280, running sun's 3.3 version of 4.2. As you stated above, a reissue of the command either results in another error (in my case the errors have been the same), or the creation of a good object file. I thought that it was a local problem that was causing the compiler to puke, since the hardware was acting a bit flaky. But, there may now be cause for further investigation... --- -john salmi -minnesota supercomputer center, inc. -minneapolis -internet: john@umn-rei-uc.arpa -or- john@uc.msc.umn.edu -uucp: {rutgers!meccts, ihnp4}!umn-cs!umnd-cs!jsalmi " instant asshole - just add alcohol... "J
jsalmi@cs.D.UMN.EDU (John Salmi) (07/20/87)
geez - feel foolish. i referred to our sun as a "2/280" rather that a "3/280".
i live for typos!
---
-john salmi
-minnesota supercomputer center, inc.
-minneapolis
- internet: john@umn-rei-uc.arpa -or- john@uc.msc.umn.edu
- uucp: {rutgers!meccts, ihnp4}!umn-cs!umnd-cs!jsalmi
" instant asshole - just add alcohol... "haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) (07/20/87)
What all this suggests is that there might be a non-repeatable hardware problem that doesn't show up except when the system is running normally. We had a case a while back which happened to be a bad Ethernet controller. It was apparently writing to addresses other than those of Ethernet buffers. So a question is, is the system doing anything else strange besides the c compiler problem? If so, you probably have a hardware problem. Diagnostics probably won't show it, because they don't get all the peripherals moving at once. In our case the bad Ethernet controller worked fine when installed in a diskless workstation, but would trash a multi-user system badly. Then there was a problem back about Versin 6 where the C compiler had only a very limited set of temp file names, so you could only do one compilation at a time, but I guess that was fixed long before 4.3 haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
jgy@hropus.UUCP (John Young) (07/21/87)
I've seen a similar (identical?) problem on 3b20's and 3b2's, always in /lib/ccom, since moving to the issue 4.0 C compiler on SVR2 on 3b2's we haven't seen the problem.