Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!apple!uokmax!occrsh!att!dptg!lzga!bogatko
From: bogatko@lzga.ATT.COM (George Bogatko)
Newsgroups: comp.unix.questions
Subject: Re: Maximum process stack size
Summary: stacks grow as necessary on 3b's
Message-ID: <1994@lzga.ATT.COM>
Date: 9 Aug 90 12:26:10 GMT
References: <1454@tub.UUCP>
Organization: AT&T BL Middletown/Lincroft NJ USA
Lines: 51

> ...does this mean the stack of a process
> can grow indefinitely?

On 3B's it does.  How did we find this out?

We had a 3B that was tuned (by default!) so that MAXUMEM was *greater*
then available swap.  MAXUMEM was tuned to be ALL the available memory
which was about 16 meg,  The default swap area is 20640 blocks, or about
10.5 meg.

A user program had the following line in it:

func()
{
char buf[100];
	
	.
	.	
	strncpy(buf, str);
	.
	.	
}

Notice that it is strNcpy, and that the last parameter is missing.  This
meant that a stupid value was passed as the third parameter, which told
strncpy to copy a huge number into buf.

Notice that 'buf' is an AUTOMATIC array, which means it is on the stack.

Well, the result was that the machine slowed down real fast, soon
you couldn't get prompt from the *console*, then finally, the machine
PANIC'd and dumped core.  

This happened because the stack (by definition, at least on this machine)
grew and grew and GREW and grew, until the process size was greater then
what could be held on the swap device.  Then the machine broke.

You can force the same condition (not recommended folks, don't just
TRY this) with:

	strncpy(buf, str, 0x7fffffff);

The fix (highly recommended) was to reset MAXUMEM from it's FACTORY DEFAULT
of ALL AVAILABLE MEMORY to something less than swap size.  When the same
program was run, it still slowed down the machine real bad, but eventually
core-dumped.

BTW, the same thing, tried on our 386 machine just core-dumped.  I suppose
they don't just grow the stack.  Replys i386 gurus?

GB