Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
--------- Received message begins Here ---------
Quoted 53 lines
--- Jesse Pollard <[email protected]>
Quoted 24 lines · wrote:
Quoted 3 lines
"This is almost always the result of flakiness in
your hardware - either
Quoted 1 line
RAM (most likely), or motherboard (less likely).
"
Quoted 2 lines
I cannot understand
this. There are many other
Quoted 1 line
stuffs that I compiled with gcc without any
problem. Again compilation is only
Quoted 1 line
a application. It only parse and gernerates
object files. How can RAM or
Quoted 1 line
motherboard makes different
It's most likely flackey memory.
Remember- a single bit that dropps can cause the
signal 11. It doesn't have
to happen consistently either. I had the same
problem until I slowed down
memory access (that seemd to cover the borderline
chip).Quoted 12 lines
The compiler uses different amounts of memory
depending on the source file,
number of symbols defined (via include headers).
When the multiple passes
occur simultaneously, there is higher memory
pressure, and more of the
free space used. One of the pages may flake out.
Compiling the kernel
puts more pressure on memory than compiling most
applications.-------------------------------------------------------------------------
Quoted 11 lines
Jesse I Pollard, II
Email: [email protected]Any opinions expressed are solely my own. -
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/
Quoted 5 lines
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 ?
Load the system down with lots of processes/large image windows. Unless the bit in question is in
a pointer, or data used in pointer arithmetic or function call it won't
segfault. Applications (if an instruction page gets hit) may get an illegal instruction.
Quoted 6 lines
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...)
Yup - because it crashed VERY frequently when it was obviously a software bug.
Quoted 7 lines
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))
Generating wrong code is different than a segfault.
Currently I'm using egcs-2.91.66 on a 486, without problems. (I don't do floating point on a 486... too slow).
Quoted 7 lines
Some time ago I installed Linux (Redhat 6.0) on my pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a couple every hour) I was upgrading
the kernel every time there was a new kernel and from 2.2.12(or 14) no more signal 11 (very rare) Is this still a hardware problem ?
Was a bug in kernel ?
Not likely - It could just depend on whether all of available was used. If the physical page with the problem doesn't get used very often, it won't show up. If the bit in question is not part of a pointer, or used in pointer arithmetic, again it won't show up (actually, any operation on addresses). Wrong, or slightly wrong results MAY show up.
Quoted 7 lines
I think the last answer is more obvious.(or the gcc had a bug and the kernel -- a workaround).
Sorry for bothering you but in every piece of linux documentation signal 11 seems to be
__identic__with hardware problem.
Bye
Only when it appears in random location.
GCC is a fairly well debugged program and doesn't segfault unless you run out of memory, or flakey memory.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.