At 10:20 AM 6/29/01, you wrote:
>Almost always ?
>It seems like gcc is THE ONLY program which gets
>signal 11
>Why the X server doesn't get signal 11 ?
>Why others programs don't get signal 11 ?
>
>I remember that once Bill Gates was asked about
>crashes in windows and he said: It's a hardware
>problem.
>It was also a joke on that subject:
>Winerr xxx: Hardware problem (it's not our fault, it's
>not, it's not, it's not, it's not...)
>
>
>Seems to me like Micro$oft way of handling problems.
>
>We must agree that gcc is full of bugs (xanim does not
>run corectly if it is compiled with gcc 2.95.3
>and other programs which use floating point
>calculations do the same (spice 3f5))
All versions of gcc have bugs. They generally show up as incorrect
complaints about the source code, as generated code that is less than
optimal or that is flat out wrong. With this kind of bug, if you compile
the program twice you'll get the same (buggy) result.
Sig 11 is a bit different. With a compiler bug causing the sig 11, the
problem will happen EVERY time you compile the given file - because the
compiler is busted. This kind of problem is detected early in the
compiler's life cycle and gets fixed.
Then there are the intermittent sig 11 errors. If the software was broken,
the sig 11 would happen whenever you do the same thing. Being able to
compile a bunch of files, get a sig 11, compile a bunch more, sig 11, a
bunch more ... is a sign that the problem isn't the compiler. Peoples'
experience over the years has shown that symptoms of this type are cause by
(intermittent) hardware problems.
Why does this affect gcc more than other programs? Because gcc uses
gazillions of pointers and bad memory causes bad pointers causes sig 11.
Hope this helps.
David
P.S. Years ago, installing OS/2 on an apparently 100% working system would
show similar problems. OS/2 was the first widely used 32 bit operating
system on Intel hardware. It exercised the hardware differently from DOS,
Windows, etc and flaky memory would make itself known. The usual reaction
was "But my system worked fine before OS/2...." The response was
"different software exercises the hardware differently and may reveal
unsuspected problems".
--------------------------------------------------------
David Relson Osage Software Systems, Inc.
[EMAIL PROTECTED] Ann Arbor, MI 48103
www.osagesoftware.com tel: 734.821.8800
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
