Re: Seg 11 in GCC
Mark,
There's a detail that bothers me about this. Just because a GCC seg fault
problem made it to the net does not mean the software was tested
thoughly. Some people pose the question because they don't know where to
start. Some other people screw around with their system (cause possibly
other problems) and then ask the question thinking they didn't screw up
their system. This is not intended as an insult to these people.
--Glenn Bily
Excerpts from mail: 31-Mar-96 Re: Seg 11 in GCC Mark Eichin@cygnus.com (1909)
> >> And if it was, in this instance, a corrupt executable, how can you
> >> assert that doesn't cast doubt on the commonly-held wisdom that
> >> _every_ SIG11 is a RAM error?
> We could wonder *how* it got corrupted, but that is a side issue. (I
> recently trashed a disk because of a motherboard flaw [laptop power
> supply overheats, everything else follows] that set the high bits on a
> bank of RAM, which was buffer cache, which got flushed to disk with
> access time updates [in theory anyway] which nuked the superblock and
> top level directories.)
> >> reinstalled GCC, at which point it worked? Did my hardware magically
> Did you in fact reinstall the same release, the same build? If there
> were *any* differences in the binary (beyond the corruption itself of
> course), it is possible that the execution pattern was changed enough
> to miss the failure.
> >> that I think the assertion that it's _always_ RAM is wrong.
> Certainly; there easy enough ways to generate a SIGSEGV by miscoding
> something, or by trashing the executable on disk. However, if the
> executable is corrupt, mucking with the RAM config won't have *any*
> effect on the failure, since the corruption is fixed into the disk
> image, and should happen "reliably". It's easy enough to tell the
> cases apart.
> Also, note that by the time someone asks about the problem on the net,
> they usually *have* eliminated "corrupted executable" as the problem
> by reinstalling; so perhaps it would be more fair to say that "all
> SIGSEGV problems that make it to the net are RAM related..." somewhat
> self-selecting, but plausible.
> And of course, "RAM" is just a short cut saying for "memory subsystem"
> which is everything from the CPU core out (cache, bus lines, A20, MMU,
> sockets, and RAM chips themselves...)
> (Just trying to expand both sides of the "argument" to make it easier
> to see common ground. Hope I've helped, and not inflamed further...)
> _Mark_
Reply to: