Crash a RISC machine from user-mode code:

[Rhodri James, the beardless wonder]

In article <1990Aug16.051437.21661 at laguna.ccsf.caltech.edu> bruce at seismo.gps.caltech.edu (Bruce Worden) writes:
>In article <17425 at haddock.ima.isc.com> karl at kelp.ima.isc.com (Karl Heuer) writes:
>>In article <1990Aug15.052856.28006 at laguna.ccsf.caltech.edu> bruce at seismo.gps.caltech.edu (Bruce Worden) writes:
>>>In article <481 at demott.COM> kdq at demott.COM (Kevin D. Quitt) writes:
>
>>>>....  But when you try to stress the system, it's going to fail.
>
>>>[Disagree.]
>
>>Clarify.  Are you saying that (a) the `crashme' program never causes your
>>machine to crash, (b) such a crash does not constitute `failure',[...]
>
> [...]    (b) that such a crash does not constitute `failure' unless it 
>significantly detracts from the machine's utility.  By `significant' I 
>mean more than a few percent of a given installation's system crashes 
>are caused by the bug.

Here I have to side with Karl. Given that the crash can happen with a
program following a rogue function pointer off into the wide blue
yonder, something which is not implausible in a development environment,
then just ignoring it is very short sighted. However you look at it,
your system is then shown to be vulnerable to crashing, deliberate or
accidental. You might consider the degree of risk acceptable in your
conditions, I certainly wouldn't accept it in an academic or commercial
development environment.

Again; you may consider the risk acceptable, just don't ask me to. I'll
see you after the next crash.

The problem is basically that your definition of "failure" is much less
stringent than mine or Karl's, or a fair number of other contributors to
this argument at a guess.
-- 
* Windsinger                 * "Nothing is forgotten..."
* rmj at islay.tcom.stc.co.uk   *                    Mike Whitaker
*     or (occasionally)      * "...except sometimes the words"
* rmj10 at phx.cam.ac.uk        *                    Phil Allcock