🚀 go-pugleaf

In article <CI8DDK.6C7@cs.utwente.nl>, rwe@cs.utwente.nl (Richard Earnshaw) writes:
|> In article <2etdvv$5kj@bigwheel.eng.sc.rolm.com>, dougv@bigwheel.eng.sc.rolm.com (D. Douglas Valkenaar) writes:
|> |> In article <CHot2q.MrL@herald.indirect.com>,
|> |> Jeffrey D. Wheelhouse <jeffw@indirect.com> wrote:
|> |> >
|> |> >1)  For some reason, my machine does not like compilers.  Now and then,
|> |> >for no apparent reason, a signal 11 will pop up in cc1 or ccom (or whatever
|> |> >it's called), depending on what stage I'm in.  If I compile again, maybe it 
|> |> >will do it again, maybe not, it is not regular.  Is my CPU getting too
|> |> >hot or something?  Or is that an old wives' tale?
|> |> >
|> |> 
|> |> I'm having the same problem on a SPARC 10 running SunOS 4.1.3.  I'll get a:
|> |> 
|> |> xgcc: Internal compiler error: program cc1 got fatal signal 11
|> |> 
|> |> but then if I run the make again, it will get past that point.  I don't only
|> |> get this while building the compiler, but even with the 2.5.0 version when
|> |> compiling other packages.
|> |> 
|> |> Very strange.
|> |> 
|> |> -- 
|> |> Douglas Valkenaar       ROLM - A Siemens Company       Santa Clara, CA
|> |> dougv@robadome.com                                      (408) 492-6119
|> 
|> Just occasionally I have seen this when a machine has run out of memory (and
|> swap space).  Does it tend to happen when compiling very large functions, or
|> when the machine is heavily loaded with other processes?
|> 
|> GCC regularly makes calls to alloca which causes allocation off the stack.  If
|> such a call "fails" then the size of the stack will have been increased beyond
|> the limits of memory available and an exception can then occur.  
|> 
|> GCC is a deterministic program, so it should always give the same results for
|> a given set of inputs.
|> 
|> Richard.

This is most probably a hardware problem. 

We went thru this about two months ago. We have two absolutely identical 
Sparcstation 10 Model 51's. One would *always* fail with a segmentation 
violation while doing a complete build of gcc. The time/location of the 
failure appeared to be totally random, but it could never successfully build
gcc from scratch. The other machine would never fail the same build, using
the exact same executables on the exact same NFS mounted disk. Never. 
We called Sun and ask them to replace the motherboard. They said "We'll send you 
a new cache controller." We said, "Why not a new motherboard?", They said "We 
**really** think you should try a new cache controller first." So we replaced 
the cache controller and everything has been fine since then.

So call your Sun service rep and ask for a new motherboard :-)

Eric Baur                   eric@synnet.com
Synernetics Inc.