Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!rice!rice!sun-spots-request
From: ames!ultra!!beau@uunet.uu.net (Beau James)
Newsgroups: comp.sys.sun
Subject: Re: Compatibility problem?
Keywords: Miscellaneous
Message-ID: <1990Aug9.022517.7473@rice.edu>
Date: 8 Aug 90 03:01:35 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 26
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 296, message 9
X-Refs:  Original: v9n296

Your automatic array is "too big" for the kernel heuristic that decides
when it's time to grow the stack, vs. when to declare a user program
error.  That heurisitc is different on Sun-3s and Sun-4s, since stack
frames tend to b different sizes on those systems.  (The heuristic may
also change from one SunOS release to another.)  This isn't really a SunOS
issue, though; the behavio of most *nixs is similar.

Unix user programs never do anything to explicitly manage the growth of
their stack.  If the program makes a reference beyond the end of currently
allocated stack [virtual] memory, the hardware traps.  The kernel looks to
see "how far" the trapped reference was beyond the end of the existing
stack; if it was "close enough", the kernel decides that the program was
really just trying to grow the stack, so it allocates additional [virtual]
memory for the stack and reruns the instruction that caused the trap -
much like a standard VM page fault.  On the other hand, if the reference
is "too far" past the stack, the kernel decides that it was indeed an
invalid reference, and sends the process a SIGSEGV.

As a general rule, this means it's a bad idea to make "big" objects
automatic.  Better to have an automatic pointer to the object, and
malloc() it on the fly; or to make the object static.  That approach is
more portable, also, since the precise definitions of "big", "too far",
etc. are very system (hardware and OS version) dependent.

Beau James				beau@Ultra.COM
Ultra Network Technologies		{sun,ames}!ultra.com!beau