GCC-3.4.2 PCH failures (segmentation faults)

Declan Moriarty declan.moriarty at ntlworld.ie
Tue Nov 9 04:39:44 PST 2004


On Fri, Nov 05, 2004 at 11:54:23PM +0000, ilja enlightened us thusly
> Hi,
> 
> I'm getting a lot of pch failures in my GCC-3.4.2 testsuite.
> I'll spare the whole list, this is a grab out of it:
> 
[snip failures] 
> in the detailed log this is the typical message:
> 
> >FAIL: gcc.dg/pch/inline-3.c  -O3 -g  (test for excess errors)
> >Excess errors:
> /source/blfs/build/gcc-3.4.2/gcc/testsuite/gcc.dg/pch/inline-3.c:2: internal
> compiler >error: Segmentation fault
> >UNTESTED: gcc.dg/pch/inline-3.c  -O3 -g  assembly comparison
> >Executing on host:
> /source/blfs/build/gcc-build/gcc/xgcc -B/source/blfs/build/gcc-build/gcc/
> ./inline-3.h   -Os    -o inline-3.h.gch    (timeout = 300)
> 
> (all failures come up the same)
> 
> I'm building my BLFS on top of lfs-6.0 build with GCC-3.4.2. There were no
> errors in the testsuite while building gcc-3.4.2 for lfs-6.0.
> Since it didn't occur during the lfs build I suspect the kernel. Could that
> be true or should i look somewhere else.
> Hope somebody can shed some light,
> 

I'd boil it all down to this:
> /source/blfs/build/gcc-3.4.2/gcc/testsuite/gcc.dg/pch/inline-3.c:2:
> internal compiler >error: Segmentation fault

A segmentation fault historically was because the 80286 cpu had 16 data
lines, but 20 address lines. How do you set the top 4? The answer was
paging or segmentation registers, used only in 'real' (simulate 80286) mode 
on 386 and later, and not used in linux, except at boot. These days it's
any memory error. Your ram fits in in places in the address space (The
limitation is usually the ram, not the cpu address space). Usual causes

	1. Faulty hardware.
	2. Sadly faulty software.

Nothing stresses a pc like building. I am not sure you are correct to 
be scrutinising devices nodes and the like, because I would expect an
error such as

can't access /dev/null

from that. I would modprobe every module you need before chrooting. From
my years of experience goofing up (and fixing electronic hardware) I
would point you to Dec's Axiom:

"When everything looks right, but it still won't work, something you are
convinced is right is actually causing your problems"

I would try the following:

1. tar the build directory after the build, and take the md5sum of the tar
Clean out or rename, repeat the build, repeat the tar, and md5sum.

2. Log your builds,  and diff the logs. This will show consistency of
failures and where they happen. Something like

diff <build log 1> <build log 2> |grep -i error |less     followed by
diff <build log 1> <build log 2> |grep -i warning |less

3. Build a kernel with the same gcc you are using. It will crap out, I
presume, but why would be illuminating. If you can get one built, boot
on it as a test.

4. Return to Dec's Axiom :-)
3. Build a kernel with the same gcc you are using. It will crap out, I
presume, but why would be illuminating. If you can get one built, boot
on it as a test.

4. Return to Dec's Axiom :-)
3. Build a kernel with the same gcc you are using. It will crap out, I
presume, but why would be illuminating. If you can get one built, boot
on it as a test.

4. Return to Dec's Axiom :-)

-- 

	With best Regards,


	Declan Moriarty.



More information about the blfs-support mailing list