Access Violation

I have some code that used to work fine, and spontaneously stopped working

It is designed to read in a file

  SUBROUTINE RDPD1( iyy )

  USE utils
  USE FUNCTIONS
  INCLUDE '..\\dims.inc'
  INCLUDE '..\\moddef.inc'
  INCLUDE '..\\testdef.inc'
  INCLUDE '..\\options.inc'
  INCLUDE '..\\read.inc'
  INCLUDE '..\\ps12\\spacepd.inc'

  INTEGER :: spin,znin,stat,iyy
  REAL :: rbuf1,rbuf2,rbuf3,rbuf4
  CHARACTER(len=8) :: progunit

! logical :: lexist,lopened,lnamed ! integer :: inumber ! character :: lseq,lunform,lread

  integer(kind=3) :: addr
  logical(kind=3) :: mode
  integer(kind=2) :: IC

  progunit='RDSPPD  '

  rdunit=77
  rdfile='sppd'//c2dfyr(JYEAR,iyy)//tstinp(iyy)//'.itm'
  
  CALL rdOpen(rdunit,rdfile,progunit)

  block='SPPD11'
  if (lfdblk(block,rdunit,rdfile)) then

    DO sp=1,mxsp
      IF( ldfsp(JISSP,sp).AND.idfsp(JISUNDER,sp)==0 )THEN
        DO zn=1,mxzf
          IF( zonedef(zn,JZTF) )THEN

**** READ(UNIT=rdunit,FMT='(2(1x,I4),4(1x,G11.0))',ERR=9999, $ IOSTAT=stat) spin,znin,rbuf1,rbuf2,rbuf3,rbuf4 **** IF( stat<0 )THEN CALL unexpectedeob(rdunit,rdfile,progunit,block) ELSEIF( stat>0 )THEN CALL errorreadingblock(rdunit,rdfile,progunit,stat,block) ELSE CALL checkSpZnOrder(sp,spin,zn,znin,progunit ) spznpd(sp,zn,JSPPDA )=rbuf1 spznpd(sp,zn,JSPSURV)=rbuf2 spznpd(sp,zn,JSPNEW )=rbuf3 spznpd(sp,zn,JSPPDV) =rbuf4 ENDIF ENDIF ENDDO ! loop over zones ENDIF ENDDO ! loop over space categories end if

  CLOSE(rdunit)
  RETURN

9999 call Access_details@(addr,mode,ic)

  ENDSUBROUTINE

The error reported is

100f28d4 IOSTART__ [+0214] RDPD1 - in file rdsppd.for at line 50 [+0308] RUNPS2 - in file runps2.for at line 17 [+00b4] main - in file ps12.for at line 63 [+04ce]

which when debugged dies before I can get an IOSTAT on it, its driving me bananas! Astrixs mark the error line, the thing that bugs me is that it reads from the file earlier on, and the format string is correct i'm sure! Any help/ideas would be gratefully received!

I should describe some of the subroutines I guess, I use every day so forget...

lfdblk(block,rdunit,rdfile) is a function that reads the file looking for the string block, returns true if it is found, then reads past that heading to the data

rdopen opens the file on rdunit, and deals with all the error handeling in one neat lump

I've tried taking the rest of the gubbins out with no successful result, should have really put up simplified code... sorry

When it used to work, was that using a different version FTN95? If so what was the old version number and what is the current version number?

Or was it a different operating system etc.

Or have you changed the code? Can you run the previous program again?

I can't remember exactly when, but I did update to 5.2.0 from 4.9.1, you've seen my other post recently on the forum (about allocating my arrays) .I updated the executable trying to fix one of the problems, it was a very frantic day, so I assume that the update broke the subroutine...

I have made every effort to ensure the correct dll and ftn95 were used in conjunction since the change

all of this is on Windows XP SP2

tried using inquire with a big list of arguments for more details too, get the error in the same IOSTART__[+0214]

Conspicuously however it was trying to read from address 00000001

Hope this can be of help

Try using the latest FTN95 patch (v5.2.1) to see if it makes any difference.

You will find the link under Announcements.

I updated the executable, still no joy Have tried to compile and run it on a couple of different machines now too. Is there anything more I can do to debug it?

You can step through the assembly code just before it fails. I think you press F11 to get the assembly view.

After that we need to know if this is a potential regression from 4.9.1. Do you still have a copy of 4.9.1 to test it against?

In the end it may be necessary for you to send us your code but I wont be able to look at it for a couple of weeks.

I'll have a look through the assembler, not sure if I'll make much sense of it im afraid, or know how to fix it should I find something!

I'm afraid I don't have a backup for ftn95 software, have an ancient CD version (2.54!) and found ftn77 3.5 on some floppies while looking

I think if I install the old version from the CD and use the the 4.9.1 service pack I can get back to where we were... I'll try it obviously, and keep you posted

Problem seems to occur in files with two read subroutines not in a module.

Can't figure why it suddenly stopped, working but the cure seems to work so far for what ever reason, guess its good practice to give subroutines their own file any how.

Hope this helps you recreate the problem and fix it if you deem it necessary

thanks