Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!decwrl!ucbvax!csnet-relay.arpa!holtz%cascade.carleton.cdn%ubc.CSNET
From: holtz%cascade.carleton.cdn%ubc.CSNET@CSNET-RELAY.ARPA (Neal Holtz)
Newsgroups: mod.computers.apollo
Subject: Guard faults (large local arrays in Fortran)
Message-ID: <446:holtz@cascade.carleton.cdn>
Date: Wed, 5-Mar-86 23:28:43 EST
Article-I.D.: cascade.446:holtz
Posted: Wed Mar  5 23:28:43 1986
Date-Received: Tue, 11-Mar-86 08:49:47 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21
Approved: apollo@yale-comix.arpa

In several different circumstances recently, we have received 'guard faults'
from Fortran programs.  Turns out that these are stack overflows, caused by
large (200,000+ byte) local arrays in subroutines (all allocated on the
stack, by default).  The reasons for this happening are quite understandable,
but it turns out that this is EXTREMELY hard for the typical Fortran user
to diagnose (even though they might otherwise be quite knowledgable).
It produces diagnostics entirely outside their realm of experience, and
is not even consistently repeatable (at least apparently).
Run it under the debugger, and the problem doesn't happen (the new cross
process debugging surely helps, but indirectly, as the fault will still
occur, but it is still not obvious as to why).
   
    [Side question.  One of these monsters run in a new shell will result in
     a guard fault.  Run it again immediately, and it seemingly works
     properly.   Why????]

I don't know what I'm suggesting, but I wish there was a better way.

Perhaps as little as a documentation section in the Fortran manual
as to the most common causes of guard faults, references to illegal
addresses, etc.