Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Sep 1998 02:39:51 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        tinguely@plains.NoDak.edu (Mark Tinguely)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: FYI: function call failures
Message-ID:  <199809230239.TAA15572@usr06.primenet.com>
In-Reply-To: <199809221907.OAA07181@plains.NoDak.edu> from "Mark Tinguely" at Sep 22, 98 02:07:14 pm

next in thread | previous in thread | raw e-mail | index | archive | help
>  *** FYI. for S/N concerns, please take comments about paper to -chat ***
> 
> from comp.arch a reference (http://www.ices.cmu.edu/ballista/ftcs98/) to
> a test of function call failures. FreeBSD did not fair too well compared
> to other OSes.
> 
>  *** FYI. for S/N concerns, please take comments about paper to -chat ***

This is not a comment about the paper; it is a comment about your
statement that "FreeBSD did not fair too well compared to other OSes".

Unfortunately, I'll have to examine the metric you are holding out
in order to make my comment.


They are counting abort() traps as a result of passing bad pointers
to library functions and system calls as "failures".  This is because:

	...In this scale, the response lies in one of six
	categories: Catastrophic (the system crashes or hangs),
	Restart (the test process hangs), Abort (the test
	process terminates abnormally, i.e. "core dump"),
	Silent (the test process exits without an error code,
	but one should have been returned), Hindering (the
	test process exits with an error code not relevent to
	to the situation), and Pass (the module exits properly,
	possibly with an appropriate error code).  Silent and
	Hindering failures are currently not found by Ballista.


In other words:

o	if you SIGSEGV from a NULL pointer dereference, you are
	a "bad" OS

o	if you silently accept bogus arguments without crashing
	or otherwise indicating an error, you are a "good" OS

o	if you silently accept bogus arguments that should have
	resulted in an error, but didn't, you are a "good" OS


To wit, this is a rehash of the following two long-lived threads:

o	FreeBSD should check for invalid pointer arguments to
	functions like strcmp and strcpy, and otherwise engage
	in idiot-proofing code, even though idiots who will call
	these functions incorrectly will not recognize an error
	response when it bites them on the arse.

o	FreeBSD should never call abort, even when data outside
	the process virtual address space is referenced, since
	even though doing so will pinpoint the exact line of
	code where the problem exists, while at the same time
	preventing cascade failures (like launching all nukes
	if a single failure causes one nuke to be launched),
	we prefer to trust the programmers to always check the
	strcpy(3) return values, because we know that all programs
	check for error returns for libc functions (yeah, right).

If you can't tell yet, I disagree with your statement about how well
FreeBSD did or did not fare.  There is a particular, and *desirable*
length to that blue bar for a POSIX compliant OS, though they fail
to state where that boundary is, unfortunately, and FreeBSD had no
catastropic errors, nor any Restart errors.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809230239.TAA15572>