Xref: utzoo alt.folklore.computers:10513 comp.unix.admin:1401 comp.unix.internals:2426 comp.unix.programmer:1434 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) Newsgroups: alt.folklore.computers,comp.unix.admin,comp.unix.internals,comp.unix.programmer Subject: Re: How do you make your UNIX crash ??? Message-ID: <1991Mar26.130653.11974@thunder.mcrcim.mcgill.edu> Date: 26 Mar 91 13:06:53 GMT References: <690@tndsyd.oz.au> <513@bria> <11313@dog.ee.lbl.gov> Followup-To: alt.folklore.computers Organization: McGill Research Centre for Intelligent Machines Lines: 30 In article <11313@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes: > [...], one should note that the more complex something is, the easier > it is to make a mistake when implementing it. Bugs are often found > in complex-addressing-mode CPUs (until fixed in a later revision) > when: > [...] We came across a most mysterious bug once: our MicroVAX suddenly started coredumping in test(1), but only for this one user. After much disbelief and head-scratching, we eventually determined that the coredump was due to something going wrong when the pushes involved in taking the trap for one of the emulated instructions involved pushing past a page boundary. I think it might have been only when it took a pagefault on the new page. The user in question had just the right size environment to tickle this. I'm still not sure exactly *what* was going wrong when this happened.... About then, we realized that the coredumps had started just about the time the service guys had done some sort of maintenance operation that involved replacing the CPU...we called them back and said "we can't really describe how it's broken; we're not entirely certain we can state it to ourselves. But it's definitely broken; please replace it". They did. (Our sysadmin at the time was good at persuasion.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu