Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Jun 2004 14:50:41 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        David Gurvich <david.gurvich@verizon.net>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Problems compiling.
Message-ID:  <Pine.NEB.3.96L.1040604144552.34555N-100000@fledge.watson.org>
In-Reply-To: <186C2F6A-B656-11D8-8266-000393AB07D8@verizon.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 4 Jun 2004, David Gurvich wrote:

> Continual segmentation faults with extended compilation.  Using
> portupgrade in a batch will fail on some ports, but will work one at a
> time.  Probably connected to trouble's with buildworld.  Has there been
> a recent change in the compiler or make program? 

There have been several similar reports recently.  However, I haven't seen
enough information to point at any single source.  The usual sources of
reports like this are:

(1) Hardware failure -- over-heating, bus problems, or memory problems.
  (1.5a) Overclocking.
(2) Hardware bug that we don't work around.
(3) VM bug.
(4) Signal bug.
(5) ABI issue in libraries and binaries.
(6) Compiler bug.

Usually (5) is easy to diagnose because it's highly reproduceable and more
than one person experiences it, although not always.  The first question
to eliminate some classes of failure modes is to determine how
reproduceable it is.  If building the same piece of software (as part of a
big build or small one) always generates the same failure in the same
place, that would be extremely useful to know about.

Usually (1) is diagnosed through measuring the environment (temperature,
etc) and replacing parts.  If you have identical hardware with an
identical problem, that sometimes confirms and sometimes eliminates
hardware failure, but replacing parts (such as memory) can be very useful
in tracking down common hardware failure modes.  (1.5a) can generally be
eliminated by not doing it. :-) 

The remainder are a bit harder, unfortunately.  Could you include a dmesg
for your hardware configuration?  Also, was there a threshold date after
which this problem started?  Is it possible for you to narrow down that
date by installing earlier snapshots of FreeBSD, perhaps down to month or
week granularity?  In particular, if you go back to earlier snapshots,
does the problem go away?

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Senior Research Scientist, McAfee Research




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040604144552.34555N-100000>