🚀 go-pugleaf

I have seen a similar problem.  It seems to be of recent origin (possibly
related to netnews or a new 9600 baud connection?).  When I print the stack
using adb I get the following:

		.
		.
		.
		.
    _intrEXIT(4,1,f7c) from fa0
    sigtramp(4,1,f7c) from 7ffff077
    _calloc() from 7562
    _intrEXIT(4,1,f7c) from fa0
    sigtramp(4,1,f7c) from 7ffff077
    _calloc() from 7562
    _intrEXIT(b,0,f7c) from fa0
    sigtramp(b,0,f7c) from 7ffff077
    _prefix(7fffee36,2e4400a8) from 5a4b
    _iswrk(a540,b9c4,a3e6,7fffee35) from 62e6
    _gtwvec(a540,a3e6,7fffee35,7fffe0f8) from 63be
    _cntrl(1,7fffee35) from 10b8
    _main(1,7fffee84,7fffee8c) from be7

Prefix() is essentially strcmp().  Upon examining 7fffee36 and 2e440a8,
I find that 7ff... is a valid string pointer but 2e... is data from a string.
Looking in iswrk(), I found that there was a static array of pointers to
strings with a dimension of 20.  A pointer to this table is indiscriminantly
incremented without checking for table overflow:

		sprintf(file, "%s/%s", dir, *listp++);

While I am not sure that this is the line that causes the failure, I noted that
the pointer had indeed been incremented beyond the bounds of the array.

At this point I had to quit hacking and get back to work, so I cannot offer the
solution.  Hopefully, this note will help someone else find the bug.

		Larry Dwyer
		Hewlett Packard Co.
		Cupertino, CA.

		..!ucbvax!hpda!ld

PS: Do not believe the return address netnews posts.  I am not `@ sri-unix'.