On 2015-08-21, Alan Grimes <[email protected]> wrote:
> Grant Edwards wrote:
>> On 2015-08-21, Alan McKinnon <[email protected]> wrote:
>>
>>> Earlier I saw segfaults in gcc, and another poster pointed it out.
>>>
>>> When gcc segfaults, it is always suspicious mostly because the compiler
>>> is an app where we know the devs take extraordinary measures to prevent it.
>>>
>>> The most common cause is faulty hardware (most often memory) as gcc
>>> tends to use all of it in ways no other app does. The usual procedure
>>> at this point is to run memtest for an extended period - say 48
>>> hours, or even 72 for an older slow machine.
>> That is definitely good advice. I've run into this situation several
>> times. A machine had bad RAM that didn't seem to cause any problems
>> under "normal" operation. But, when trying to compile something large
>> like gcc, I would see non-repeatable segfaults (it wouldn't always
>> segfault at the exact same point). In those cases, I could often run
>> memtest for several passes and not see an error. But, _eventually_
>> ramtest would catch it. Run memtest for a few days. Really.
>
> Yeah, I know there's a single bit error out at the end of RAM that
> will appear on the third or fourth pass...
And you're still using it? And when it doesn't work, you blame
blaming _us_?
**PLONK**
> It just doesn't seem reasonable to demand that every bit in a 32
> gigabyte memory bank be absolutely perfect....
Idiot.
Of _course_ software expects memory to work. Why don't you stop
bothering us and go write an OS that doesn't depend on RAM working
properly.
--
Grant Edwards grant.b.edwards Yow! Now KEN and BARBIE
at are PERMANENTLY ADDICTED to
gmail.com MIND-ALTERING DRUGS ...
