Compilation troubles due to system or hardware

Compilation troubles due to system or hardware

Post by Fabrice P. Lauss » Sun, 23 Apr 2000 04:00:00



Hi,

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.

I'm not too sure wether this is due to gcc or what, but installation
will fail for 9 programs out of 10 I try to compile. Recently for
instance, I've been unable to install the Perl Tk module (doing the
usual perl -MCPAN -e shell then install Tk). There'll be segmentation
fault, the machine will hang, cc will receave a kill signal, a kernel
panic will occur, or other problems like that. I've been unable to
install bash or emacs (from their sources, binaries goes okay) for the

same reasons. I've reinstalled gcc, changes nothing.

When I reboot the system brutally (for the machine is frozen), the
file system is messep up of course, but may be the disk is damaged and

a library or a code is corruped (running short of money, I'm using a
five years old machine).

When the installation problem will occur, nothing will work
thereafter, for instance a `ls' will either cause a seg-fault or hang
the terminal. I can't even reboot, the machine hangs.

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).

I don't know what the error can be, but it isn't one due to my lack of

knowledge on how to install a program... there's obviously something
rotten with the system or the hadware. I'd like to have a system or
low level guru's point of view.

Regards.

F.P.L.

 
 
 

Compilation troubles due to system or hardware

Post by Dances With Cro » Sun, 23 Apr 2000 04:00:00


On Sat, 22 Apr 2000 06:32:41 +0200, Fabrice P. Laussy

Quote:>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.
[snip]
>When the installation problem will occur, nothing will work
>thereafter, for instance a `ls' will either cause a seg-fault or hang
>the terminal. I can't even reboot, the machine hangs.
>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

I'm not sure, but I *think* this is caused by problems with your RAM.  gcc
is very memory-intensive.  Have you tried getting the memtest86 utility
and checking out your system's RAM?

Conversely, it could be a problem with your gcc.  Some versions of gcc
were flaky wrt doing optimizations and complex things like that. what's
the output of "gcc --version"?

--
Matt G / Dances With Crows              \###| Programmers are playwrights
There is no Darkness in Eternity         \##| Computers are lousy actors
But only Light too dim for us to see      \#| Lusers are vicious drama critics
(Unless, of course, you're working with NT)\| BOFHen burn down theatres.

 
 
 

Compilation troubles due to system or hardware

Post by Robie Bas » Sun, 23 Apr 2000 04:00:00


On Sat, 22 Apr 2000 06:32:41 +0200, Fabrice P. Laussy said:

Quote:>Hi,

>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.

>I'm not too sure wether this is due to gcc or what, but installation
>will fail for 9 programs out of 10 I try to compile. Recently for
>instance, I've been unable to install the Perl Tk module (doing the
>usual perl -MCPAN -e shell then install Tk). There'll be segmentation
>fault, the machine will hang, cc will receave a kill signal, a kernel
>panic will occur, or other problems like that. I've been unable to
>install bash or emacs (from their sources, binaries goes okay) for the

>same reasons. I've reinstalled gcc, changes nothing.

>When I reboot the system brutally (for the machine is frozen), the
>file system is messep up of course, but may be the disk is damaged and

>a library or a code is corruped (running short of money, I'm using a
>five years old machine).

>When the installation problem will occur, nothing will work
>thereafter, for instance a `ls' will either cause a seg-fault or hang
>the terminal. I can't even reboot, the machine hangs.

>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).

>I don't know what the error can be, but it isn't one due to my lack of

>knowledge on how to install a program... there's obviously something
>rotten with the system or the hadware. I'd like to have a system or
>low level guru's point of view.

I reckon that some part of your filesystem has become corrupted; when
fsck repairs after a crash, have you ever seen anything actually
being fixed?

If various programs do it, it is most likely to be your kernel image
or part of glibc.

Do an fsck manually first.

You didn't say which distribution you were using; if Redhat then I
know you can verify the integrity of installed files using the rpm
command; do:
  for i in `rpm -qa`; do rpm -V $i;done
This will give you a list of files you should check; if anything
in /boot or /lib or /usr/lib is present (or anything related to gcc),
then this could be your problem.

(man rpm will give you an explanation of the output).

For other distributions, tell us what you have and someone who
knows it will tell you, I'm sure.

Robie.
--

 
 
 

Compilation troubles due to system or hardware

Post by Grant Edwar » Sun, 23 Apr 2000 04:00:00



Quote:>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:

 http://metalab.unc.edu/pub/Linux/docs/faqs/GCC-SIG11-FAQ

[...]

Quote:>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.

 
 
 

Compilation troubles due to system or hardware

Post by Fabrice P. Lauss » Mon, 24 Apr 2000 04:00:00



> I'm not sure, but I *think* this is caused by problems with your RAM.  gcc
> is very memory-intensive.  Have you tried getting the memtest86 utility
> and checking out your system's RAM?

Well, now that's something done, but it reports no error. Please see my reply to
Grant Edwards herebelow, whose advices were related to yours.

Quote:> Conversely, it could be a problem with your gcc.  Some versions of gcc
> were flaky wrt doing optimizations and complex things like that. what's
> the output of "gcc --version"?

my version is 2.7.2.3.

F.P.L.

 
 
 

Compilation troubles due to system or hardware

Post by Fabrice P. Lauss » Mon, 24 Apr 2000 04:00:00



> I reckon that some part of your filesystem has become corrupted; when
> fsck repairs after a crash, have you ever seen anything actually
> being fixed?

Well, hundreds time, yes, of course. This has ever resulted in *apparent*
lost of data, both system (instances are X fonts, files in /etc, or log
files) or personnal, especially those I was working on. Most of the time,
I'm looking in lost+found what has dropped dead, and try to see if there's

something I can do... Otherwise I let it go and hope for the best.

Quote:> If various programs do it, it is most likely to be your kernel image
> or part of glibc.

Well, I thought that too, so once I saved all my data, formatted the whole

disk, and installed a brand new system. The same day did I encounter
another very similar problem, thus excluding it was due to corruption of
files on the disk (because a non-corrupted file-system with non-corrupted
libc, etc..., brought up the same problem).

Quote:> Do an fsck manually first.

Every time I have to reboot brutally, fsck will force a check itself,
usually fixing some inodes with illegal blocks, and time to time needing
some manual repair from myself. Nothing tells however this is a problem
with the disk. Those are natural consequences of rebooting without
unmounting the fs first. I know I have ever lost data the way you say
(till the day I'll loose everything), but it seems like I still haven't
suffered problems on system sensible components (like a shared library).
The problem seems to be one of memory.

Quote:> You didn't say which distribution you were using; if Redhat then I

I'm using Debian. I've posted in a debian list a question about how to
reinstall something like the glibc (for Debian has a powerful yet annoying

system of dependencies I can't overcome).

Thanks for your help.

F.P.L.

 
 
 

Compilation troubles due to system or hardware

Post by Fabrice P. Lauss » Mon, 24 Apr 2000 04:00:00



> >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:

>  http://www.veryComputer.com/

> [...]

> >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
document!)

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
related
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.

Regards.

F.P.L.

 
 
 

1. compilation problems due to super_block->s_mounted

compiling hpfs yields: (I tried 2.1.4[56])

make[2]: Entering directory `/usr/src/linux/fs/hpfs'
make all_targets
make[3]: Entering directory `/usr/src/linux/fs/hpfs'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 \
-fomit-frame-pointer -pipe -fno-strength-reduce -m486 -DCPU=486  -c \
-o hpfs_fs.o hpfs_fs.c
hpfs_fs.c:140: warning: initialization from incompatible pointer type
hpfs_fs.c:142: warning: initialization from incompatible pointer type
hpfs_fs.c:143: warning: initialization from incompatible pointer type
hpfs_fs.c:178: warning: initialization from incompatible pointer type
hpfs_fs.c:181: warning: initialization from incompatible pointer type
hpfs_fs.c:212: warning: initialization from incompatible pointer type
hpfs_fs.c: In function `hpfs_read_super':
hpfs_fs.c:488: structure has no member named `s_mounted'
hpfs_fs.c:491: structure has no member named `s_mounted'
hpfs_fs.c:504: structure has no member named `s_mounted'
hpfs_fs.c:513: structure has no member named `s_mounted'
hpfs_fs.c:514: structure has no member named `s_mounted'
hpfs_fs.c:515: structure has no member named `s_mounted'
make[3]: *** [hpfs_fs.o] Error 1
make[3]: Leaving directory `/usr/src/linux/fs/hpfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/fs/hpfs'

since 2.1.44 in struct super_block (fs.h) the pointer
struct inode *s_mounted has been replaced by a pointer
struct dentry *s_root.
linux/fs/hpfs/hpfs_fs.c seems to have been not adapted to that.

BTW: in 2.1.46 I can find "s_mounted" also in:
        affs/inode.c
        ncpfs/inode.c
        nfsd/export.c
        nfsd/vfs.c
        romfs/inode.c
        smbfs/inode.c
        umsdos/dir.c
        umsdos/inode.c
        umsdos/rdir.c
which I don't use - and can't tell if "s_mounted" might be
commented out or would still prohibit compilation.

Wolfgang Schober


2. Q: The best way to download redhat5.1

3. Help:xlC says compilation ended due to lack of space

4. sendmsg not implemented yet ?

5. debian 2.2 r3 on RAID hardware system -troubles-

6. Fix for ATAPI CD/DVD-ROMs and burners with vt8235 (and other chipsets)

7. Are Ethernet frame errors due to hardware or software?

8. reset,free a ttyp ?

9. Oops due to hardware failure?

10. Interrupt trouble due to IRQ router VIA?

11. Going crazy due to SLIP trouble...

12. performance problems (due to mixed system?)