Xref: utzoo news.software.b:4406 comp.unix.wizards:21107
Path: utzoo!utstat!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: news.software.b,comp.unix.wizards
Subject: Re: anne.jones dumps core
Message-ID: <3054@auspex.auspex.com>
Date: 20 Mar 90 03:11:43 GMT
References: <1990Mar15.185725.27695@ccu.umanitoba.ca> <1990Mar16.191820.9978@utzoo.uucp>
Followup-To: comp.unix.wizards
Organization: Auspex Systems, Santa Clara
Lines: 48

>(This is all the more disgusting because the problem that is most
>likely to be to blame was understood years ago, and Geoff's paper
>"A Partial Tour Through the UNIX Shell" at San Diego Usenix explained
>it and how to fix it.)

Well, it depends on which problem you're thinking of.

The SunOS 3.2 Bourne shell was scoured for the "catch SIGSEGV and grow
the 'stack'" hack.  (Actually, the BRL Bourne shell - based, like the
SunOS 3.x one, on the S5R2 Bourne shell - was the one that was scoured,
and the changes were later applied to the 3.x one, but I digress....)

Unfortunately, not all of the problems were caught (no, not all of the
places where you have to check use "pushstak()", and we didn't rewhack
the handling of the "stack" as much as you did).  Some are still present
in the 4.0 shell, but I think are fixed in the 4.1 shell. 

BTW, comments on a couple of statements in the paper:

	1) "The Ninth Edition (and presumably System V Release 2) shell
	   used some of the directory(3) routines from the C library..."

	   Nope.  The S5R2 shell couldn't use the directory routines
	   from the C library since they weren't in the S5R2 C library.

	2) "The performance impact [of checking manually rather than
	   having the MMU do it] has not been measured, but appears to
	   be insignificant."

	   At one point, I compiled two versions of the shell, identical
	   except that one did the checks and one depended on the
	   "SIGSEGV hack", on a 3B2/400 running S5R3 (it happened to be the
	   nearest handy system that 1) had an OS that could
	   conveniently compile an S5-based shell like the SunOS 3.x one
	   and 2) made the "SIGSEGV hack" work) and tried doing

		echo `cat *.c`

	   in the hopes it'd really stress the code where the checks
	   appeared.

	   The performance impact was, in fact, insignificant, at least
	   for that test.

	   I'm curious what the performance impact was on the original
	   PDP-11(s) on which the work was done, given that John Mashey
	   has claimed, as I remember, that Bourne put the SIGSEGV hack
	   in at his urging in order to speed up the shell.