if your GCC (or binutils) gets signal 11, READ THIS!

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Simon Karp » Mon, 20 Mar 1995 03:52:11



Lately, there has been lots of discussion of GCC or the binutils
(ld, as, etc) getting fatal signal 11. This is NOT a problem with GCC,
the binutils, the kernel, or any other software. Signal 11 means that
you have bad RAM or cache on your system. The first step is to disable
the processor cache (level 2). If GCC stops getting the signal, you need to
replace the cache. Otherwise, run a MS-DOG based RAM test program in
its most comprehensive mode. If it finds a problem, you have a bad
SIMM (or chip) that needs to be replaced. If it does not find
problems, this does not mean that you do not have bad RAM, as GCC and
company are the world's best memory tester. You then need to try only
part of your memory at a time to isolate the bad RAM.
                        Simon
--
*****************************************************************************

*  flames to /dev/null                  Linux: choice of the GNU generation *
*  #include <disclaimer.h>                          I don't speak for NCSSM *
*****************************************************************************
 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Greg Jesus Wolodk » Mon, 20 Mar 1995 12:28:41




>Lately, there has been lots of discussion of GCC or the binutils
>(ld, as, etc) getting fatal signal 11. This is NOT a problem with GCC,
>the binutils, the kernel, or any other software. Signal 11 means that
>you have bad RAM or cache on your system. The first step is to disable
>the processor cache (level 2). If GCC stops getting the signal, you need to
>replace the cache.

Easy now -- my Award BIOS lets me mess with the DRAM timing (most do)
and in fact the parameter labeled `DRAM burst speed', with choices of
{slowest, slower, faster, faster}, can cause me to get signal 11.

Reducing the burst speed from `fastest' to `faster' causes a modest
decrease in throughput (if you believe, e.g. comptest to be relevant)
but it also makes signal 11 go away.

Point is you probably don't need to buy new chips -- just be a little
less agressive with your BIOS settings.  Besides, for the price of a
new cache you could almost buy a new motherboard ;-)

Cheers,
Greg

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Nicolas Scharna » Tue, 21 Mar 1995 19:00:59


Well, I have this problem with the GCC i2.6.3 pentium. So how do I disable the processor cache on linux in practice?
The signal comes for example at sched.c for cc1 when compiling linux 1.2.0
On the other hand, GCC 2.6.2. works fine as a 486.
Feel free to mail me directly.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.i

mQCNAi9dussAAAEEAM1BBK2yaIa06MtFDMCeVZoDnhEAidX1WbOXMiLPmRDOClV/
glQF7CjleyU2ygeZta4GVTocLaRbYvVJqCKyCRfzJN0sFbB+6VWStSL3OJOizYGg
7WzUwZSup9NaLtWDBZ+6hs0Flu0yAJltQgPZCD+ZFbe07GJX64+/3Ovu43WxAAUR
tC5OaWNvbGFzIFNjaGFybmFnbCA8bWFzZWdhbmRAc3R1ZC5waHlzLmV0aHouY2g+
=jSKH
-----END PGP PUBLIC KEY BLOCK-----

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Steven J. Mads » Thu, 23 Mar 1995 03:56:03



> Well, I have this problem with the GCC i2.6.3 pentium. So how do I disable the processor cache on linux in practice?
> The signal comes for example at sched.c for cc1 when compiling linux 1.2.0
> On the other hand, GCC 2.6.2. works fine as a 486.
> Feel free to mail me directly.

        I've had this problem myself, with each and every version of Pentium
gcc.  It's not your motherboard at all, it's the Pentium gcc having
problems.

        Try turning off ALL optimizations.  It always worked for me.  But,
Pentium gcc with no optimizations isn't going to outperform 486 gcc with
optimizations, so I dumped the Pentium version and am patiently (?) waiting
for GNU to integrate official support.  HOPEFULLY that will work..

--

Systems Administrator/Programmer
Cliometric Society, Miami University

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Mikael Abrahamss » Fri, 24 Mar 1995 02:47:37




>Other programs either do not use so much memory, or use it to store mostly
>data values, not addresses.  So, a memory error in such a program will
>"merely" cause bad program results, not signals.
>(the error chances are also increased by use of a lot of memory in a
>random pattern, something that GCC also likes to do)

>When GCC fails on your system and other programs "run OK", it is certainly
>time to fix the cache.  Other programs may be failing in a less obvious
>manner.

I got a lot more of these problems (like at least a factor of 10) when I
upgraded from 8 to 16 megs of ram. I disabled L2 (external) cache, and it
hasnt showed up ever since (compiled the kernel several times last night
when installed a new sfx card).

There was some discussion going on a couple of months about 128kb cache
was good for 8-16 megs of ram. I fou got more ram, you needed to upgrade
the cache to 256 or 512 kb. Does anyone know anything about this?
(myself, if it's not very expensive, I'm going to upgrade to 256 kb cache
and try it)

Regards.

--
-----
Mikael Abrahamsson

Student vid Instutitionen f|r Informatik vid Lunds Universitet, Sweden.

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Aaron 'Raz' Wrasm » Fri, 24 Mar 1995 03:57:58


Okay before I upgraded to gcc 2.6.2 I never got this error.  I
upgraded to gcc 2.6.2 around kernel 1.1.94 or .95 I don't remember
which but I do remember getting this error when I compiled the kernel.
I got it again when I compiled 1.2.0 and 1.2.1. I got it alot with I
compiled 1.2.1 I was curious so I dropped back to an older
kernel. (1.1.75) and compiled the kernel 1.2.1 I didn't get the errer
at all. I didn't compile gcc 2.6.2 myself, I just grabbed the binary
off of sunsite and I'm wondering if something has changed in the
kernel since that binary was made that causes this problem. Compiling
with GCC is the only time I got this error. I just remember also when
trying to compile 1.2.1 under 1.2.0 that I also got a kernel oops
everytime I got signal 11 with gcc 2.6.2

I do have the latest bdflush also. (I make sure of that when I go home
tonight.)

Raz

--

 (!=>---   http://www.cs.utk.edu/~wrasman
 / ) Raz   Usnail: 602B Longview Rd Knoxville,TN 37919

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Christopher Wil » Fri, 24 Mar 1995 05:17:13



> Lately, there has been lots of discussion of GCC or the binutils
> (ld, as, etc) getting fatal signal 11. This is NOT a problem with GCC,
> the binutils, the kernel, or any other software. Signal 11 means that
> you have bad RAM or cache on your system. The first step is to disable
> the processor cache (level 2). If GCC stops getting the signal, you need to
> replace the cache. Otherwise, run a MS-DOG based RAM test program in
> its most comprehensive mode. If it finds a problem, you have a bad
> SIMM (or chip) that needs to be replaced. If it does not find
> problems, this does not mean that you do not have bad RAM, as GCC and
> company are the world's best memory tester. You then need to try only
> part of your memory at a time to isolate the bad RAM.

You also get a signal 11 when you try to link ELF object files with a.out
crt0.o, and vice versa.

FYI.


              9A 26 98 E6 03 F4 B8 0F  97 D8 0C 1F CC 16 3A C7

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Joe Rhe » Sat, 25 Mar 1995 02:46:27



>: : Lately, there has been lots of discussion of GCC or the binutils  (ld,
>: : as, etc) getting fatal signal 11. This is NOT a problem with GCC, the
>: : binutils, the kernel, or any other software. Signal 11 means that you
>: : have bad RAM or cache on your system.
>It sounds like your problem was repeatable.  The problem to which Simon
>refers isn't.  The compiler will crash in random places in files that
>compiled fine the last time and will compile fine the next time.  Typically
>people run into it when recompiling a kernel, and in my experience it seems
>to be cc1 most of the time. If you just keep doing a make it eventually
>compiles everything, but I wouldn't trust the results. ;)
>The _random_ signal 11 when compiling stuff is almost always a memory or bus
>problem.  (It was memory when it happened to me.) If gcc always chokes on a

Actually, I can verifiably prove that it's _NOT_ always memory, but the
kludged fashion in which someone keeps patching the gcc versions. If you
acquire 2.5.8, compile and install it, then acquire 2.6.3 and compile and
install it yourself then you won't have any problems.

If you get the binaries from sunsite or tsx11, you can't even compile 2.6.3
with them because of error 11 problems.  I've gone back and recompiled
2.6.3 again with an older version and all my signal 11s are GONE.

This is a plea to the Linux developers:

LEAVE GCC ALONE, PLEASE.  You may like to play on your own private
playgrounds, but I firmly believe that the pre-compiled versions of GCC on
the commonly-accessed Linux homes SHOULD NOT CONTAIN YOUR OWN PRIVATE FUN
AND GREAT ENHANCEMENTS! (Or, at the very least, should be documented as
such, with UNENHANCED VERSIONS AVAILABLE!)

I'm tired of spending hours playing with things someone else has tweaked
because "it's better that way" ...  "Better that way" doesn't apply when we
need to compile commonly available software ... and most of us aren't at
the level to "fix" that software to match your tweaking.

--
-----                                                                   -----
Joe Rhett                                                       Navigist, Inc.
Systems Engineer                                                (408) 397-5803

My opinions are not my own, they are those of my cat. I have no opinions.

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Linus Torval » Sat, 25 Mar 1995 17:28:02




>Let's say you've got a system with 4M RAM and 2M swap.  You've got one
>really big C file to compile.  Let's say GCC needs 7M to compile this
>one file.  So, it starts up, and when it tries to access the 7th meg,
>GCC gets a signal 11 and dies.

>Is this a clear indication of a bug?  Where is the bug?

>On this system, this file will reliably cause GCC to crash.  On
>another Unix system, when GCC tried to malloc() more memory than the
>system had, it would say "oh, I don't have enough memory", and would
>terminate normally.  On Linux, malloc() basically never fails --
>instead, your program crashes when you actually try to *use* the
>memory you don't have, so you'd get something like a "signal 11".

>This is exactly the problem being discussed under the "linux is
>creating memory" thread.

No.  The probelm with "linux is creating memory" is that none of the
people who complain about the behaviour has actually even *tested* it,
at least not with a real program.  Why don't you?

Linux malloc *does* return NULL.  Really.

Gcc won't get SIGSEGV because the machine runs out of memory.  Really.

Most of the discussion in "linux is creating memory" thread has been
pure and stupid flamage, often without ever testing the behaviour, and
often with people reading some standards text and trying to work out
something that the standard doesn't really cover.

How about testing the following simple program:

        int main()
        { printf("%p\n", malloc(1024*1024*1024)); }

(and no, it's not a strictly conforming program, dammit, stop being so
fixated by standards).

The kernel *does* overextend it's memory use in certain circumstances,
and yes, it's a bit too easy to do it, but no, I'm not stupid.  And when
it does overextend its resources, it clearly tells you so: *if* it ever
kills a program due to not having memory, it will clearly say so with a
nice message like "Out of memory for XXX." where XXX is the name of the
program it will kill, and then it will kill it with SIGKILL, not
SIGSEGV.

And believe me: by the time you see this message, you will probably have
noticed it yourself for quite a while because the kernel has done a lot
of work trying to find free pages (throwing out code pages etc), and the
machine hasn't exactly been responsive for a while.  Often for *quite* a
while.

Oh, you can get SIGSEGV's for programs when memory is tight, just
*because* malloc will possibly return NULL, and not all programs will
check the return value (I suspect this may be worse in places where you
don't malloc() anything explicitly, but depend on the library or
language features like "new" to do it for you).  gcc should be pretty
good at not doing this, though.

                Linus

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Thomas Koen » Sun, 26 Mar 1995 08:05:27




Quote:>The kernel *does* overextend it's memory use in certain circumstances,
>and yes, it's a bit too easy to do it, but no, I'm not stupid.

~linux/kernel/sys.c:

asmlinkage int sys_brk(unsigned long brk)
[...]
        /*
         * stupid algorithm to decide if we have enough memory: while
         * simple, it hopefully works in most obvious cases.. Easy to
         * fool it, but this should catch most mistakes.
         */

:-)
--

The joy of engineering is to find a straight line on a double
logarithmic diagram.

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Valient Gou » Sun, 26 Mar 1995 03:32:09




: > Well, I have this problem with the GCC i2.6.3 pentium. So how do I disable the processor cache on linux in practice?
: > The signal comes for example at sched.c for cc1 when compiling linux 1.2.0
: > On the other hand, GCC 2.6.2. works fine as a 486.
: > Feel free to mail me directly.

:       I've had this problem myself, with each and every version of Pentium
: gcc.  It's not your motherboard at all, it's the Pentium gcc having
: problems.

:       Try turning off ALL optimizations.  It always worked for me.  But,
: Pentium gcc with no optimizations isn't going to outperform 486 gcc with
: optimizations, so I dumped the Pentium version and am patiently (?) waiting
: for GNU to integrate official support.  HOPEFULLY that will work..

  When you compile the kernel with gcci, use -O2, not -O3 or above.  O2
isn't the best optimization, but it is better then no pentium opts.  I'm
running 1.2.1 compiled with gcc-i2.6.3 (-O2 -mpentium) right now.  I have
sucessfully compiled a kernel with -O3, but there are a couple files that
have to be done with -O2.  I don't have any way to tell how much faster it
is though.

regards,
Val

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Steve Pel » Mon, 27 Mar 1995 10:57:23




>The kernel *does* overextend it's memory use in certain circumstances,
>and yes, it's a bit too easy to do it, but no, I'm not stupid.  And when
>it does overextend its resources, it clearly tells you so: *if* it ever
>kills a program due to not having memory, it will clearly say so with a
>nice message like "Out of memory for XXX." where XXX is the name of the
>program it will kill, and then it will kill it with SIGKILL, not
>SIGSEGV.

Ok, you're right, I was assuming that people were correct in this
discussion. I just now tried it and indeed, it sends a SIGKILL when
you try to allocate a swap page and none are available. However, I
could not find anything that put out a message "Out of memory for XXX".
Is that supposed to show up in syslog or where?

So much for the clever routines that touch each page in an attempt to
guarantee that there is swap space...you can't catch a SIGKILL.
--
Steve Peltz

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Han Hol » Mon, 27 Mar 1995 00:47:49


> -------------------------------------------------------------------------------
>      Subject: Re: if your GCC (or binutils) gets signal 11, READ THIS!
>         Date: 24 Mar 1995 10:28:02 +0200

> Organization: University of Helsinki
>   Newsgroups: comp.os.linux.development.apps, comp.os.linux.development.system,
>               comp.os.linux.hardware
>   References: 1 , 2 , 3 , 4

>     -----------------------------------------------------------------------
[ text omitted ]
> check the return value (I suspect this may be worse in places where you
> don't malloc() anything explicitly, but depend on the library or
> language features like "new" to do it for you).  gcc should be pretty
> good at not doing this, though.

>                 Linus

> ----------------------------------------------------------------------------

One of the 'good' features of C++ new is that a new - handler gets installed
so that no malloc _ever_ goes unchecked.
New is much safer than plain malloc.

Han

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Gerry George operat » Tue, 28 Mar 1995 06:13:01




: : : Lately, there has been lots of discussion of GCC or the binutils  (ld,
: : : as, etc) getting fatal signal 11. This is NOT a problem with GCC, the
: : : binutils, the kernel, or any other software. Signal 11 means that you
: : : have bad RAM or cache on your system.

: [...]

: : This really isn't true...

: Well, it is mostly.

: : It just means that GCC is trying to access memory it doesn't own.... I've
: : gotten this lots of times while using templates and objects.  Just check
: : your code.  Commenting out large blocks to isolate the error works well for
: : this situation.  I once spend over an hour tracking down what was a missing
: : ; (which made my statement legal, but gave it a totally  different
: : meaning).

: It sounds like your problem was repeatable.  The problem to which Simon
: refers isn't.  The compiler will crash in random places in files that
: compiled fine the last time and will compile fine the next time.  Typically
: people run into it when recompiling a kernel, and in my experience it seems
: to be cc1 most of the time. If you just keep doing a make it eventually
: compiles everything, but I wouldn't trust the results. ;)

My way around this is to "rm" the last compiled segment or the one gcc (cc1)
died on and restart the make.  Eventually I get to the end with a working
program.


        Law is too important to be left to lawyers, which is why
        judges and juries, not lawyers decide legal disputes.
        ========================================================

 
 
 

if your GCC (or binutils) gets signal 11, READ THIS!

Post by Michael W » Wed, 29 Mar 1995 02:31:07


It might NOT be the bad SIMM.  It might only means that SIMM is not cooled
properly!!!

After upgrading my 386/40 to a 486 DX4-100, I started getting GCC signal 11
(sometime Signal 4, illegal instruction).  Thinking 486 is much more
demanding to the memory, I remove the case the touch the SIMM chip.  It's
much much hotter than it used to be when I do the kernel compiling.
After I put an electric fan beside the uncovered machine and cool the chips,
I tried compiling the kernel five times in a roll and even use the "make -j"
parallel compiling and I stopped getting those signals.  I put the
case back and the kernel compiling failed again.

This means the SIMMs are OK, but just too hot by providing data to the 486
monster.  What I need is a better ventilated case (those twin-fan ones).

--Mike

: Lately, there has been lots of discussion of GCC or the binutils
: (ld, as, etc) getting fatal signal 11. This is NOT a problem with GCC,
: the binutils, the kernel, or any other software. Signal 11 means that
: you have bad RAM or cache on your system. The first step is to disable
: the processor cache (level 2). If GCC stops getting the signal, you need to
: replace the cache. Otherwise, run a MS-DOG based RAM test program in
: its most comprehensive mode. If it finds a problem, you have a bad
: SIMM (or chip) that needs to be replaced. If it does not find
: problems, this does not mean that you do not have bad RAM, as GCC and
: company are the world's best memory tester. You then need to try only
: part of your memory at a time to isolate the bad RAM.
:                       Simon
: --
: *****************************************************************************

: *  flames to /dev/null                  Linux: choice of the GNU generation *
: *  #include <disclaimer.h>                          I don't speak for NCSSM *
: *****************************************************************************

--
Mike Z. Wei
MSAM Unix support

1221/21 296-7275

 
 
 

1. Getting Signal 11 Fatal Error w/ GCC and Linux 1.0.9

I have had linux 1.0.9 up and running for about 2 months. Every thing is working fine except the GCC compiler.  When I compile code especially large jobs, I get a gcc error (11). I think this is an out of memory error, but I am not out of memory.  When I get the error I can usually do another make and the compiler will
continue where it left off. Sometimes it won't.  I have traced the problem t
 [A
swap space.  If I swapoff and swapon after the error, I can continue every time.
So it seems that something in the Swap space is being corrupted.

Is this a Linux Kernel bug.  Any of you familar with it?

Other information, I am using the SCSI, NET-2 kernel and GCC version 2.5.8.

Also, does anyone have some tips for tuning the kernel for performance when supporting multiple users on Ethernet?

Thanks in advance for you assistance.

Ric Anderson, Dept. of Information Technology, Commonwealth of Virginia

2. page table...

3. Can't compile console.c: gcc gets signal 11

4. need a sample SMB.CONF file for WindowsNT network

5. cannot compile Apache on HPUX 11 using gcc 2.95.3 and binutils 2.11

6. Boston Computer Society Linux/UNIX SIG Meeting

7. gcc reports inernal compiler error: cc1 got fatal signal 11 always!?!

8. Help with modem (etc.) in SuSe 7.0 (please!)

9. signal 11 on gcc

10. gcc Signal 11

11. gcc fatal signal 11 - I WANT to get it !!

12. GCC fatal signal 11 error (compiling 2.0.35)

13. GCC and the 'signal 11' problem, HELP!