Consistant buildworld Segmentation fault at '===> gnu/usr.bin/cc/cpp' after latest RELENG_5 cvsup

[Doug White]

On Mar 9, 2005, at 10:50 AM, Aaron Daubman wrote:

> Hi Doug,
>
>>> ===> gnu/usr.bin/cc/cpp
>>> Segmentation fault (core dumped)
>>> *** Error code 139
>> [...]
>>
>> The typical reason for segfaults is bad hardware.  A v20z is a pretty
>> decent server class machine, though, so unless its suffering from an
>> undetected condition it should scream bloody murder if something goes
>> bad. This is assuming it has ECC memory and you aren't ignoring that
>> big yellow "maintenance" light that comes on when something bad
>> happens, like a fan going down.
>>
>> Can you get into the LOM and check the environmentals?
>
> Everything is showing up as "Nominal" status.
> One note that might make a difference:
> The system is a Dual Opteron - not single.  I was going by dmesg
> output (and since GENERIC is non-SMP...), not on what I had actually
> ordered (or LOM status showed ;-).

Ok, good to check that.

> Also, isn't segfault usually only indicative of hardware failure when
> it does not reliably occur at the exact same spot?

Not necessarily. It could be a pattern-related failure. If it was a 
software bug I'd expect more reports of problems. V20z's are pretty 
common.

> I should mention that this box was running some fairly intensive
> network management software under Windows 2003 server for a month or
> so solid as well - which would make me lean away from hardware
> faults...

Unfortunately that proves nothing.  It casts doubt on a hardware fault 
but cannot exclude it entirely, due to differing OS access patterns.

> Any suggestions as to what to change HT settings to - or if that's a
> worthwhile avenue to go down?

Opterons don't support HyperThreading, so there will be no option to 
turn it off.

You might try installing 5.3-RELEASE and trying to build up from there. 
That might replace whatever the broken file is that cvsup can't detect. 
You may need to temporarily move the system down to 4GB of RAM to work 
around a bug in the release.

Also check the system date & time ... if they are off even by a few 
days you can get weird failures when building.

--
Doug White                    |  FreeBSD: The Power to Serve
dwhite at gumbysoft.com          |  www.FreeBSD.org