Xref: utzoo comp.unix.microport:3008 comp.unix.questions:12367
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!rochester!uhura.cc.rochester.edu!ur-valhalla!micropen!dave
From: dave@micropen (David F. Carlson)
Newsgroups: comp.unix.microport,comp.unix.questions
Subject: Re: C bug causes double fault
Message-ID: <660@micropen>
Date: 22 Mar 89 18:07:09 GMT
References: <244@tree.UUCP> <9884@smoke.BRL.MIL> <27245@cci632.UUCP> <9900@smoke.BRL.MIL>
Organization: Micropen Dirent Writing Systems, Pittsford, NY
Lines: 29

In article <9900@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <27245@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes:
> >On Microport V/AT, what he wrote causes a kernel panic.  
> 
> Of course nobody would call it "reasonable", but it's not too surprising.
> Incorrect user-mode code on a nonprotected multitasking system (forced by
> limitations of the PC/AT architecture) can easily crash the entire system.
> For another example, when testing newly written DMD applications downloaded
> into my (AT&T 5620 or 630) terminal, some bugs cause the whole terminal
> to die and have to be rebooted.  That's just the nature of environments
> without hardware memory protection.
> 

Begging your pardon, but although the 80286 has an odd segmented scheme for
memory management, it is not non-protected when running Unix SV in anyway
I am familiar with the term.  Perhaps you are too quick to flame that which
you know not of.

The truth is that Microport early versions had the potential to corrupt the
kernel stack on floating point exceptions, which is what this should be.
This was supposedly fixed several versions ago and I never had saw this
again.  (It was a showstopper though for a multi-user development machine:
too insecure to use.)

-- 
David F. Carlson, Micropen, Inc.
micropen!dave@ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll