segfaulting gcc - FreeBSD

[Jiri]

Hello,
I have system running:
FreeBSD wopice.valleyofdeath.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed
Feb 16 13:05:24 CET 2005
valleyofdeath.net:/usr/obj/usr/src/sys/WOPICE i386
and I have noticed that lots of ports fail to build because of "internal
compiler error" from GCC... Okay, so I supposed there is something
rotten in GCC, so I've tried to upgrade to 5.4-PRERELEASE, and surprise
surprise, I've got internal compiler error when building bootstrap tools:
-------------------------------------------------------------- [/ref][/ref]
--------------------------------------------------------------
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR=
INSTALL="sh /usr/src/tools/install.sh"
PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
WORLDTMP=/usr/obj/usr/src/i386 MAKEFLAGS="-m /usr/src/tools/build/mk
-m /usr/src/share/mk" make -f Makefile.inc1 BOOTSTRAPPING=503102
-DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED
-DNO_CPU_CFLAGS -DNO_WARNS bootstrap-tools
===> gnu/usr.bin/gperf
/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/gperf created for
/usr/src/gnu/usr.bin/gperf
===> gnu/usr.bin/gperf/doc
/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/gperf/doc created for
/usr/src/gnu/usr.bin/gperf/doc
rm -f .depend
mkdep -f .depend -a -I/usr/obj/usr/src/i386/legacy/usr/include
-I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib
-I/usr/src/gnu/usr.bin/gperf
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc
In file included from
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc:0:
<internal>:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
mkdep: compile failed
*** Error code 1

Stop in /usr/src/gnu/usr.bin/gperf.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
rootwopice:/usr/src#
==
no go... So my question is - is there some clean way to get out of this
without reinstalling the system, or am I doomed?

TIA
--
Jiri Novak

[Alex]

Jiri Novak wrote:
 

Does the error always occur in the same place? If not, then it is
possible you have a hardware fault.

A segmentation fault results from bad memory access, which could be a
program(mer) fault, but in something as well developed as GCC, they
ought never to happen.

If it is a hardware fault, the likely culprits are memory and disk. Do
you have any interesting messages in /var/log/messages?

--Alex

[Jiri]

Alex Zbyslaw wrote: 
>
>
> Does the error always occur in the same place? If not, then it is
> possible you have a hardware fault.
>
> A segmentation fault results from bad memory access, which could be a
> program(mer) fault, but in something as well developed as GCC, they
> ought never to happen.
>
> If it is a hardware fault, the likely culprits are memory and disk. Do
> you have any interesting messages in /var/log/messages?
>
> --Alex[/ref]

The error always occur at the same place, in ports (it was firefox and mplayer
for sure, not quite sure about others) and in buildworld, so I don't suspect
faulty hardware.
No useful messages in /var/log/messages...
Well, it seems that I'm doomed :(
--
Jiri Novak

[Jiri]

Jiri Novak wrote: 

I hate to followup to myself, but I solved the problem... in a way :)
I did download base distribution of 5.4-BETA1 and replaced my b0rken
/usr/libexec/cc* binaries with "clean" ones. After that I'd rebuilt
world and kernel with more sane optimization settings (I was using -O2,
which probably caused the problem) and everything works happily, ports
are building with no segfaults.
If anybody have the same problem and is as desperate as I was (the system
is physically almost unacessible for me), this may be the quick and dirty
solution...
--
Jiri Novak

[Jiri]

Jiri Novak wrote: 

I hate to followup to myself, but I solved the problem... in a way :)
I did download base distribution of 5.4-BETA1 and replaced my b0rken
/usr/libexec/cc* binaries with "clean" ones. After that I'd rebuilt
world and kernel with more sane optimization settings (I was using -O2,
which probably caused the problem) and everything works happily, ports
are building with no segfaults.
If anybody have the same problem and is as desperate as I was (the system
is physically almost unacessible for me), this may be the quick and dirty
solution...
--
Jiri Novak

[Jiri]

Jiri Novak wrote: 

I hate to followup to myself, but I solved the problem... in a way :)
I did download base distribution of 5.4-BETA1 and replaced my b0rken
/usr/libexec/cc* binaries with "clean" ones. After that I'd rebuilt
world and kernel with more sane optimization settings (I was using -O2,
which probably caused the problem) and everything works happily, ports
are building with no segfaults.
If anybody have the same problem and is as desperate as I was (the system
is physically almost unacessible for me), this may be the quick and dirty
solution...
--
Jiri Novak