This error is very rare to do with a software problem - it's a hardware
one. In my particular case, it was the cache; 100% of the time I could get
a sig 11 with the old cache in compared to the new cache, yet the old cache
worked fine under other OSs' like Win95 etc.
In the GCC-HOWTO it explains the following:
-----
Signal 11 is SIGSEGV, or `segmentation violation'. Usually it means
that the program got its pointers confused and tried to write to
memory it didn't own. So, it could be a gcc bug.
gcc is however, a well tested and reliable piece of software, for the
most part. It also uses a large number of complex data structures,
and an awful lot of pointers. In short, it's the pickiest RAM tester
commonly available. If you can't duplicate the bug --- if it doesn't
stop in the same place when you restart the compilation --- it's
almost certainly a problem with your hardware (CPU, memory,
motherboard or cache). Don't claim it as a bug because your computer
passes the power-on checks or runs Windows ok or whatever; these
`tests' are commonly and rightly held to be worthless. And don't
claim it's a bug because a kernel compile always stops during `make
zImage' --- of course it will! `make zImage' is probably compiling
over 200 files; we're looking for a slightly smaller place than that.
------
Regards
-- Karl Ferguson Tower Networking Pty Ltd Tel: +61-8-9456-0000 karl@tower.net.au t/a STAR Online Services Fax: +61-8-9455-2776 karl@debian.org