c===========================================================
c     segf: Program carefully crafted to generate a 
c     'Segmentation fault' with a minimum of fuss
c
c     Try 
c
c     % segf 1
c     % segf 10
c     % segf 100
c     % segf 1000
c     % segf 10000
c          .      
c          .      
c          .      
c
c     until something interesting happens, then enable 
c     tracing via, e.g. 
c
c     % segf 1000 1
c
c     to get a closer view of the problem.
c
c     XXX
c===========================================================
      program      segf

      character*4  p 
      parameter  ( p = 'segf' )

      integer      iargc, i4arg
      real*8       c(1), sum
      integer      i, offset, ltrace 

c-----------------------------------------------------------
c     Argument parsing, note default value for trace is off.
c-----------------------------------------------------------
      if( iargc() .lt. 1 ) go to 900

      offset = i4arg(1,-1)
      if( offset .le. 0 ) go to 900

      ltrace = i4arg(2,0)
      if( ltrace .ne. 0 ) then
         write(0,*) p//': Tracing enabled, offset = ', offset
      end if

c-----------------------------------------------------------
c     Now accumulate the sum of sin(i) , i = 1 .. offset
c     and accumulate individual sin(i)'s in c(i), which is 
c     a scalar.  Eventually the program tries to access data 
c     at a (system) address for which it has no access.
c
c     RULE OF THUMB 1: If your Fortran 77 program generates 
c     a 'Segmentation fault', the smart money is  you've 
c     overflowed the bounds of an arrray.
c
c     A good compiler will have a bounds checking option that
c     may make the code hideously slow, but which WILL enable
c     verification of the bounds of all array references.
c
c     Alternatively, debugging such problems is, of course, a 
c     perfectly valid use of a debugger!
c
c     (Note the use of techniques such as unknown-until-run-time
c     bounds on do-loops, and the possible output of all values
c     calculated, as well as the sum, to inhibit smart compilers 
c     from deducing that the program never produces any output 
c     and thus not executing at all, or figuring out the 
c     output from the static structure of loop bounds etc.)
c-----------------------------------------------------------
      sum = 0.0d0
      do i = 1 , offset
         c(i) = sin(1.0d0*i)
         sum = sum + c(i)
         if( ltrace .ne. 0 ) then
            write(*,*) i, c(i), sum
         end if
      end do
      write(*,*) offset, sum

      stop

 900  continue
         write(0,*) 'usage: '//p//' offset [trace]'
         write(0,*) ' '
         write(0,*) '       offset -> positive integer ~< 2G '
         write(0,*) '       trace  -> positive integer enables trace'
      stop

      end