Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Ive also had a problem with signal 11, heres a great page explaining the aspects of signal 11 error from gcc (http://www.bitwizard.nl/sig11/). Signal 11 is usually a hardware problem, as the article points out. I found a sloppy soulution playing with my BIOS settings, turns out there was an option called "Memory Hole at 15Mb Addr." I enabled it and i got no more sig11, however when I boot up, Linux only recognizes like 13Mb of my 64Mb of RAM. Anyway, there are my 2 cents. Luis -- ___ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup FREE PC-to-Phone calls with Net2Phone http://www.net2phone.com/cgi-bin/link.cgi?121 - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Ive also had a problem with signal 11, heres a great page explaining the aspects of signal 11 error from gcc (http://www.bitwizard.nl/sig11/). Signal 11 is usually a hardware problem, as the article points out. I found a sloppy soulution playing with my BIOS settings, turns out there was an option called Memory Hole at 15Mb Addr. I enabled it and i got no more sig11, however when I boot up, Linux only recognizes like 13Mb of my 64Mb of RAM. Anyway, there are my 2 cents. Luis phlash -- ___ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup FREE PC-to-Phone calls with Net2Phone http://www.net2phone.com/cgi-bin/link.cgi?121 - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Riley Williams wrote: > Hi Peter. > > >> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? > > > Perhaps, but is has absolutely nothing to do with the rest of > > this discussion. > > The `lock halt` bug patch was specific to the Cyrix processors (not to > be confused with the `lock registers` patch for the Intel processors, > and I noted that the processor in question was a Cyrix one, hence the > comment. > Oh. Sorry, I don't know about "lock halt" and its effects. However, if it refers to the instruction sequence LOCK HLT I find it hard to believe it would have the symptoms described. -hpa - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Riley Williams wrote: > > Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? > Perhaps, but is has absolutely nothing to do with the rest of this discussion. -hpa - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Followup to: <[EMAIL PROTECTED]> By author:szonyi calin <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > 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 ? > gcc happens to be one of the best memory testers known to man -- much better than most other programs. A big reason for that is that it accesses lots of memory in funny patterns, *AND* accesses to it are likely to be fatal. It is just the way it is. gcc doing the signal 11 is HIGHLY correlated with the hardware you are running on, which means it's *usually* hardware-related. > [... Lots of M$ flames ignored ...] > 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 ? > > I think the last answer is more obvious.(or the gcc > had a bug and the kernel -- a workaround). Most likely is that your *hardware* had a bug and the new kernel a workaround (this is quite common), but without more detail it is very hard to know. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Followup to: [EMAIL PROTECTED] By author:szonyi calin [EMAIL PROTECTED] In newsgroup: linux.dev.kernel 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 ? gcc happens to be one of the best memory testers known to man -- much better than most other programs. A big reason for that is that it accesses lots of memory in funny patterns, *AND* accesses to it are likely to be fatal. It is just the way it is. gcc doing the signal 11 is HIGHLY correlated with the hardware you are running on, which means it's *usually* hardware-related. [... Lots of M$ flames ignored ...] 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 ? I think the last answer is more obvious.(or the gcc had a bug and the kernel -- a workaround). Most likely is that your *hardware* had a bug and the new kernel a workaround (this is quite common), but without more detail it is very hard to know. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Riley Williams wrote: Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? Perhaps, but is has absolutely nothing to do with the rest of this discussion. -hpa - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
Riley Williams wrote: Hi Peter. Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? Perhaps, but is has absolutely nothing to do with the rest of this discussion. The `lock halt` bug patch was specific to the Cyrix processors (not to be confused with the `lock registers` patch for the Intel processors, and I noted that the processor in question was a Cyrix one, hence the comment. Oh. Sorry, I don't know about lock halt and its effects. However, if it refers to the instruction sequence LOCK HLT I find it hard to believe it would have the symptoms described. -hpa - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
> 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 ? ... > 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 ? It could be. One possible way: 1. your system is clogged with dust 2. gcc runs the CPU hard, generating lots of heat 3. the heat causes crashes 4. a new Linux version that sets a Cyrix-specific power-saving mode 5. your heat problems go away, and so do the crashes Another possible way: 1. you have buggy motherboard or disk hardware 2. when you swap, gcc gets corrupted by the hardware 3. you get a new Linux kernel that has a bug work-around 4. your problems go away Yet another way: 1. your room is hot, your computer is near a huge motor... 2. you upgrade to Linux 2.2.12 and move your computer 3. soon you realize that the crashes are gone 4. you credit the kernel, but location was the problem - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
- Received message begins Here - > > > --- Jesse Pollard <[EMAIL PROTECTED]> > wrote: > > > > > > > > > "This is almost always the result of flakiness in > > your hardware - either > > > RAM (most likely), or motherboard (less likely). > > " > > > > > > I cannot understand > > this. There are many other > > > stuffs that I compiled with gcc without any > > problem. Again compilation is only > > > a application. It only parse and gernerates > > object files. How can RAM or > > > 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). > > > > 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. > > > > > - > > 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/ > > 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. > 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. > 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). > 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. > 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. - 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/
Re: gcc: internal compiler error: program cc1 got fatal signal 11
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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
--- Jesse Pollard <[EMAIL PROTECTED]> wrote: > > > > > > "This is almost always the result of flakiness in > your hardware - either > > RAM (most likely), or motherboard (less likely). > " > > > > I cannot understand > this. There are many other > > stuffs that I compiled with gcc without any > problem. Again compilation is only > > a application. It only parse and gernerates > object files. How can RAM or > > 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). > > 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. > > - > 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/ 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)) 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 ? 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 __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
> > > "This is almost always the result of flakiness in your hardware - either > RAM (most likely), or motherboard (less likely). " > > I cannot understand this. There are many other > stuffs that I compiled with gcc without any problem. Again compilation is only > a application. It only parse and gernerates object files. How can RAM or > 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). 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. - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
On Thu, Jun 28, 2001 at 11:23:37PM -0600, Blesson Paul wrote: > > "This is almost always the result of flakiness in your hardware - either > RAM (most likely), or motherboard (less likely). " > > I cannot understand this. There are many other > stuffs that I compiled with gcc without any problem. Again compilation is only > a application. It only parse and gernerates object files. How can RAM or > motherboard makes different Please read the complete Sig11 FAQ (http://www.bitwizard.nl/sig11/ ), your question is discussed in it as well. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
On Thu, Jun 28, 2001 at 11:23:37PM -0600, Blesson Paul wrote: This is almost always the result of flakiness in your hardware - either RAM (most likely), or motherboard (less likely). I cannot understand this. There are many other stuffs that I compiled with gcc without any problem. Again compilation is only a application. It only parse and gernerates object files. How can RAM or motherboard makes different Please read the complete Sig11 FAQ (http://www.bitwizard.nl/sig11/ ), your question is discussed in it as well. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
This is almost always the result of flakiness in your hardware - either RAM (most likely), or motherboard (less likely). I cannot understand this. There are many other stuffs that I compiled with gcc without any problem. Again compilation is only a application. It only parse and gernerates object files. How can RAM or 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). 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. - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
--- Jesse Pollard [EMAIL PROTECTED] wrote: This is almost always the result of flakiness in your hardware - either RAM (most likely), or motherboard (less likely). I cannot understand this. There are many other stuffs that I compiled with gcc without any problem. Again compilation is only a application. It only parse and gernerates object files. How can RAM or 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). 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. - 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/ 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)) 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 ? 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 __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - 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/
Re: gcc: internal compiler error: program cc1 got fatal signal 11
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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
- Received message begins Here - --- Jesse Pollard [EMAIL PROTECTED] wrote: This is almost always the result of flakiness in your hardware - either RAM (most likely), or motherboard (less likely). I cannot understand this. There are many other stuffs that I compiled with gcc without any problem. Again compilation is only a application. It only parse and gernerates object files. How can RAM or 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). 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. - 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/ 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. 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. 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). 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. 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. - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
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 ? ... 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 ? It could be. One possible way: 1. your system is clogged with dust 2. gcc runs the CPU hard, generating lots of heat 3. the heat causes crashes 4. a new Linux version that sets a Cyrix-specific power-saving mode 5. your heat problems go away, and so do the crashes Another possible way: 1. you have buggy motherboard or disk hardware 2. when you swap, gcc gets corrupted by the hardware 3. you get a new Linux kernel that has a bug work-around 4. your problems go away Yet another way: 1. your room is hot, your computer is near a huge motor... 2. you upgrade to Linux 2.2.12 and move your computer 3. soon you realize that the crashes are gone 4. you credit the kernel, but location was the problem - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
"This is almost always the result of flakiness in your hardware - either RAM (most likely), or motherboard (less likely). " I cannot understand this. There are many other stuffs that I compiled with gcc without any problem. Again compilation is only a application. It only parse and gernerates object files. How can RAM or motherboard makes different - 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/
gcc: internal compiler error: program cc1 got fatal signal 11
hi I am trying to compile the kernel2.4.5 source code. Presently I have kernel2.2.14 and Redhat6.2. I have egcs1.2.2. Now when I compile I will get the following error gcc: Internel compiler error: program cc1 got fatal signal 11 make Error 1 Leaving directory ... .. . Assembler messages Warning: end of file not at end of file: newline inserted cpp: output pipe has been closed Error: suffix or operands invalid for mov Here cofusion part is that, when I recompile, the same part where this error occured will compile perfectly. But again after some compilation, the same error will show in any other place. The last line in the error statement may be different in the second time. Moreover my cpu info in given below. I have given processor i486. Is there any particular choice should be made to compile kernel source code processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 400.921117 fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow bogomips: 799.54 - 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/
gcc: internal compiler error: program cc1 got fatal signal 11
hi I am trying to compile the kernel2.4.5 source code. Presently I have kernel2.2.14 and Redhat6.2. I have egcs1.2.2. Now when I compile I will get the following error gcc: Internel compiler error: program cc1 got fatal signal 11 make Error 1 Leaving directory ... .. . Assembler messages Warning: end of file not at end of file: newline inserted cpp: output pipe has been closed Error: suffix or operands invalid for mov Here cofusion part is that, when I recompile, the same part where this error occured will compile perfectly. But again after some compilation, the same error will show in any other place. The last line in the error statement may be different in the second time. Moreover my cpu info in given below. I have given processor i486. Is there any particular choice should be made to compile kernel source code processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 400.921117 fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnow bogomips: 799.54 - 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/
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
This is almost always the result of flakiness in your hardware - either RAM (most likely), or motherboard (less likely). I cannot understand this. There are many other stuffs that I compiled with gcc without any problem. Again compilation is only a application. It only parse and gernerates object files. How can RAM or motherboard makes different - 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/
