Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!mit-eddie!apollo!oj
From: oj@apollo.HP.COM (Ellis Oliver Jones)
Newsgroups: comp.sys.apollo
Subject: Re:  GUARD FAULT ?
Message-ID: <476c0e1a.20b6d@apollo.HP.COM>
Date: 14 Dec 89 14:57:00 GMT
References: <8912131524.AA17942@richter.mit.edu>
Sender: root@apollo.HP.COM
Reply-To: oj@apollo.hp.com
Organization: Apollo Computer, Chelmsford, MA
Lines: 30

In article <8912131524.AA17942@richter.mit.edu> krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes:
>A guard fault means you overran the end of the stack space.

Yes. If you use the "las" ("list-address-space") utility
in /usr/apollo/bin/las  (Not Just Like Real Unix) on a typical process,
you'll get something like this (349 is the Unix PID, and this is SR10.2,
but "las" in some form works on all SRs).  <area nnn> means a hunk of 
virtual memory which is not associated with a file.  The change which allowed
the Prism to take 0.5 meg per process instead of 

% las 349
       VA Range    Obj Start   Pathname
    8000 -     FFFF        0   <area 157>
   10000 -    17FFF        0   <area 164>
3B2A0000 - 3B2AFFFF 7FFF0000   <area 159>
3B2D0000 - 3B2EFFFF 7FFE0000   <area 176>
3B340000 - 3B377FFF        0   /sys/node_data/systmp/dm_mbx
3B378000 - 3B37FFFF 7FFF8000   <area 163>
3B380000 - 3B3C7FFF 7FFB8000   <area 142> <---stack pointer in here.
3B3C8000 - 3B3CFFFF        0   /sys/node_data/systmp/stack_guard_file 
3B3D0000 - 3B3F7FFF        0   <area 173>
 . . .
3B528000 - 3B537FFF        0   /lib/kslib
3B538000 - 3B54FFFF        0   /lib/rgylib
3B550000 - 3B55FFFF        0   /lib/ddslib
3B560000 - 3B56FFFF        0   /lib/ftnlib
 . . .
4672 KB mapped.

/Ollie Jones (speaking for myself, not necessarily for HP Apollo)