Re: Seg 11 in GCC
>> 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: