Re: Seg 11 in GCC
In message <[🔎] xe1g2ao7rh0.fsf_-_@maneki-neko.cygnus.com>, Mark Eichin writes:
>>> 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'm fairly certain that it was corrupted because I was running with a
DPT Fast/Wide SCSI-2 card and a kernel before than 1.3.80.
Again, I only have empirical evidence to back me up, in the form of a
system that only started working reliably after once I created a
custom boot floppy so that I never used a prior kernel at any point
during installation or usage.
Hopefully Leonard Zubikoff will flush most remaining bugs out of the
SCSI subsystem. He seems to have made a good start.
>>> 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.
Yep, I installed gcc-2.7.2-5.deb both times.
>>> 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.
True, and certainly demonstrable in my case. Howcome everyone still
seems hell-bent on telling me its my memory? :-)
I guess that's what annoys me---the absolute assertions that start to
fly the moment someone says "SIG11". Watching linux-(gcc|kernel), it
starts to sound like the "real" message is that "Linux couldn't
possibly be to blame, it must be your hardware" statement.
That position smacks of far too many discussions I've had with
Microsoft tech support. I'd be much more comfortable if people quit
trying to fix blame and instead tried to explain the actual issues.
>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...)
Don't forget swap partitions and, by extension, hard drive
controllers.
>(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...)
No flames here.
Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."
Reply to: