Segmentation fault during make buildworld
Justin Hopper
jhopper at spry.com
Fri Apr 25 13:22:49 PDT 2003
On Fri, 2003-04-18 at 22:48, Lin, Tsung Ching wrote:
> hi,
> I tried to upgrade 4.8-stable to 5.0-release, but i got problems.
> I updated the source tree using cvsup, and followed the instructions in
> /usr/src/UPDATE.
> during the 'make buildworld' phase, I got a compiling error messages as
> follows.
> I had tried to upgrade several times, and got the same problem.
> can you help me to solve this problem??
> thank you very much .
>
> c++ -O2 -pipe -march=i686 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
> -I/usr/src/gnu/lib/libstdc++
> -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
> -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fmemoize-lookups
> -fsave-memoized -fno-implicit-templates -ffunction-sections
> -fdata-sections -Wno-deprecated -c strstream-fixed.cc -o
> strstream-fixed.o
> c++ -O2 -pipe -march=i686 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
> -I/usr/src/gnu/lib/libstdc++
> -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
> -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fmemoize-lookups
> -fsave-memoized -fno-implicit-templates -ffunction-sections
> -fdata-sections -Wno-deprecated -c
> /usr/src/contrib/libstdc++/src/bitset.cc -o bitset.o
> c++ -O2 -pipe -march=i686 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
> -I/usr/src/gnu/lib/libstdc++
> -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++
> -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fmemoize-lookups
> -fsave-memoized -fno-implicit-templates -ffunction-sections
> -fdata-sections -Wno-deprecated -c
> /usr/src/contrib/libstdc++/src/functexcept.cc -o functexcept.o
> /usr/src/contrib/libstdc++/src/functexcept.cc: In function `void
> std::__throw_invalid_argument(const char*)':
> /usr/src/contrib/libstdc++/src/functexcept.cc:65: internal error:
> Segmentation
> fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
The only time I have seen this is with faulty memory. The memory will
get past a POST memory check and even run the system fine, but a
'buildworld' seems to stress the memory enough to find these minor
glitches.
In the past, I have cleaned up the source, shut down, removed a stick of
memory, try to make the world again. If it fails again, remove a
different stick, etc. Perhaps somebody else can suggest a better way to
do it, but without a memory testing device, trial and error was the only
option I had at the time.
--
Justin Hopper
jhopper at spry.com
UNIX Systems Engineer
http://www.spry.com
More information about the freebsd-questions
mailing list