Re: Seg 11 in GCC
mdorman@lot49.med.miami.edu (Michael Alan Dorman) wrote on 31.03.96 in <[🔎] m0u3UZH-00027sC@lot49.med.miami.edu>:
> In message <[🔎] 65lIw6ljcsB@khms.westfalen.de>, Kai Henningsen writes:
> >You have *one* case where the reason *may* be something different.
>
> How else can you explain the fact that I tried _several_ times to
> compile a single file (conmakehash.c), and got SIG11s until I
> reinstalled GCC, at which point it worked? Did my hardware magically
> get better? Or, could it be that it was a corrupt executable?
It could have been caused by a different usage pattern. This has already
been explained.
Note that I don't say that that's what happened; I *do* say that it
doesn't change the statistics, regardless of what was the reason in your
case.
> >On the other hand, there are at least thousands of cases where it
> >*clearly* was a hardware problem - hardware fiddling made it go away.
> >Apply the math yourself.
>
> Oh, come now, unless you can document your assertion of "at least
> thousands of cases where it *clearly* was a hardware problem",
> "Applying the math" hardly matters because your data is suspect.
Easy. Go through the news and the linux mailing lists. Look for cases
where this happened, and was resolved one way or the other.
That's the data I'm speaking of.
There's nothing suspect about it. And it's pretty one-sided.
(Also compare my personal experiences, which I also posted here.)
> Would you have had as much problem with my last paragraph if I had
> said, "That would tend to cast significant doubt on the common
> assertion that a SIG11 in GCC can _always_ be inextricably linked to a
> hardware problem, no?"
Then I'd said that nobody ever made that particular assertion - it's a
straw man.
Nobody says it's always a RAM problem. We _do_ say that it's _almost_
always a hardware problem (and it may be bad RAM, bad timing, or several
other options).
MfG Kai
Reply to: