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