> >I've got big problems with compilation. I can compile simple and
> >little C source, but I often encounter segmentation-fault when I
> >attempt to compile huge source.
> If it occurs randomly (not at the same point every time, or
> sometimes a file will compile and sometimes it won't), then
> it's almost certainly a hardware problem: flakey RAM, cache,
> overheated CPU, etc. There a sig11 FAQ at www.linuxdoc.org:
> >If I can compile something, that's okay, but when a problem
> >arises once, it will be impossible to go through for this
> >programm intended to be installed, the fatal error occuring at
> >different places in the process of compilation (say, at the
> >very start, or near the end for another try).
> Definitely hardware. When it happend to me it was cache. Take
> a look at the sig11 faq file.
> Grant Edwards grante Yow! Finally, Zippy
> at drives his 1958 RAMBLER
> visi.com METROPOLITAN into the
> faculty dining room.
I think we're close to the problem. I've looked carefully at your link
(Thanks!) and to Mr. Dances with Crows's memtest tool (apparently from the same
author), which track memory errors which result in the following events:
1. Signal 11 being received when compiling
2. Lots of disk corruption problems
3. X windows crashing often.
4. A generally unstable system.
Then, it happens that I meet this very four problems!
Anyway, of all my numerous memory tests I never was able to trace even one bit
error, though as claimed, that doesn't prove anything (what an enthralling
If the problem is one of bad-luck, due to so many pointers manipulations with
gcc compiling the kernel that it will break almost certainly, I wonder why is
that I can never compile through all of the Tk module which is such a little
innocent looking stuff. I've compiled gcc many times without problem, which is
a far tougher thing than pTk.
In the FAQ it is said those symptoms can be due to a poor filesystem too (and
refering to point 2., those are problems I have too).
There are things with my machine which sounds odd in regards to the FAQ. I
think they can interest you.
1) whenever a signal is caught and the compilation interrupted, my machine
*always* responds by failing to run anything else: I can't log anymore, can't
reboot, can't `ls', can't do anything but reboot in brute force, screwing up
the file-system. Either the command (such as `ls' will retourn a seg-fault, or
return nothing,* the terminal). Well, if the problem in the first place
was one of a bit to be flipped in gcc's internal memory, that wouldn't explain
this behaviour, would it?
2) on reboot (the brute force reboot following such a crash), I invariably meet
a problem in uncompressing Linux on startup. That runs "Loading linux..." and
hangs. I have to let the machine shut down (power off) for a minute or two, as
if for the memory to recover, and then reboot. There's mentionned in the FAQ a
problem with CRC, uncompressing Linux, mentionned as occuring time to
time. With me it's *all* the time.
3) This isn't only widely encountered with compilation. Netscape and
Mathematica, when those are having a great deal with the disk (Netscape) or CPU
(Mathematica), are often frozing the machine or bugging all the other
applications, just the same as for gcc... I thought before those were not
to my compiling failures but were software specifics. Now I'm fairly sure the
problem stems from what causes failure of compilation.
I'm afraid, due to the fact I have to reboot then repair the filesystem, I
won't be able to run all the tests adviced in the FAQ. I just cannot do
"another make", as asked, and thanks but I don't think I'll start a test that
will take me two or three months... I've tried a compilation of the Tk module
with the memory caches (both internal and external) removed. Apart from slowing
down up to 25 times the stuff, it didn't prevent a "segmentation fault" to
occur. So for me it isn't the cache...
I know we're close to the problem. You certainly found it right guys... Thanks
for it. Anyway, I think the solution will be to suffer it, as I do for years
now, and find a way to install Tk without compiling him... Fixing the hardware
doesn't seem a practical solution... better yet to buy a brand new machine.