Acces Violation: Clearwin64

I'm busy with updating an old Fortran program (compiled with FTN95/win32 /Clearwin+/v 2.52). I made some changes to the original scripts so that I should be able to compile it with the 64 bits compiler. However I get an access violation message when compiling one of the scripts.

Runtime error from program:c:\program files (x86)\silverfrost\ftn95\ftn95.exe Access Violation The instruction at address 1004d45d attempted to read from location 0000001a

1004d3b3 __user_integer(<ref>(<ptr>char)) [+00aa]

100949ee do_format_code(<ref>(<ptr>char),<ref>(<ptr>char),int,int,int,enumÄlogical,enumÄ [+2bac]

100a3cf1 __winio [+0b11]

00566661 do_winio_check(<ptr>structÄtree_record)#77 [+04f5]

00566c73 amd_do_function(<ptr>structÄtree_record) [+00f7]

0055e44c AmdCodeGenerator(<ref>structÄtree_ptr) [+37ca]

00569712 amd_do_equals(<ptr>structÄtree_record) [+033b]

0055e44c AmdCodeGenerator(<ref>structÄtree_ptr) [+37ca] [recur= 1]

eax=0b8f8460 ebx=03d4e570 ecx=0000001a edx=00000042 esi=00000000 edi=03d4e534 ebp=03d4db20 esp=03d4dafc IOPL=0 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00210212 [NC OP NZ SN DN NV]

1004d45d mov eax,[ecx] 1004d45f jmp 1004d4c0 1004d464 jmp 1004d4c0

I tried to find what is going wrong and I think it has something to do with this part of a script, and then the last line.

      integer function fbound()

!
      use carray
      use grey
      use hipwin
      use iarray
      use isingle
      implicit none
!     Called functions
      integer , external :: grddsp,fbclst,sav_name,bctest
      integer , external :: fblft,fbcedt,fbcadd,fbcdel,fbcdsp,fbrit
      integer , external :: fbfrt,fbbac,fbfpb,fball,fbcall,fblpr

      if(nc2 == 20) then
        gradd=0
      else
        gradd=1
      endif
      if(nc2 > 0) then
        grbor=0
        grdel=1
        grdsp=1
        gredt=1
      else
        grbor=1
        grdel=0
        grdsp=0
        gredt=0
      endif      

      ans=winio@('%ca[ Specified Flux Conduction Boundaries]&')
      ans=winio@('%mi[hstinpicon]&')
      ans=winio@('%ww[no_maxminbox]&') 
      ans=winio@('%sy[3d]&')
      ans=winio@('%bg[Grey]%tc[Black]&')

      ans=winio@('%mn[~&Edit]&',gredt,fbcedt)

gredt is defined in a module as integer :: gredt I can change it to integer*8, or integer (kind=9), but then I get the error code that gredt should be an integer....?

Any suggestions?

The access violation occurred in the compiler itself (FTN95.exe), when it was asked to compile your code. You need to provide the complete source codes(s), including any source files that contain the modules used by the test Fortran code that caused the violation, and information on the compiler version and compiler options used.

You should change windows handles to integer8 or integer(7). Clearwin 'handles' can remain as integer4. Providing an integer8 size handle when only integer4 is required should not cause a problem, but returning an integer4 could have a problem. Providing an integer4, when an integer8 is required will likely cause a run-time problem, either as an access violation, or more likely as an overwrite of a near variable. (Dan would call this response devilry!) Mixing of real4 and real*8 also produces these problems.

Recent versions of FTN95 have introduced some more checking of integer types, which may help.

I do not know if the access violation in FTN95 is due to selecting integer(9) or some other problem with /64.

The current release of FTN95 provides winio@ argument checking at compile time but only with /64 and /CHECK. What you have amounts to an FTN95 bug that may have already been fixed for the next release. If you can send me your code then we can check this out.

The first thing to do is to compile the program without /CHECK (or anything that implies /CHECK). Run the program to see if winio@ argument faults are revealed at runtime. If there is a fault then you can see what it is to fix it. Then you may be OK to proceed as before. Otherwise...

winio@ argument checking at compile time can be switched off by adding /INHIBIT_CHECK 16 to /CHECK.

Thanks for the reactions.

I'm using the personal version 8.10 and I downloaded it on 12 September 2017

If I compile all files without CHECK and link them (with SLINK64), an exe is created with the only warning that the following symbols were not defined: DRAW_LINE@ GET_MOUSE_POSITION@

This should be easy to solve by including DBOS.INS. Should I use the statement USE or INCLUDE ?

When I start the program I get the following error.

Silverfrost 64-bit exception report on C:\hstwin\Hstinpal64.exe Thu Sep 21 09:50:13 2017

Access violation (c0000005) at address 76d4d1e9

Within file ntdll.dll In RtlIsDosDeviceName_U at address 94C9 In GlobalFree at address 32 Within file KERNELBASE.dll In GlobalFree at address 21 Within file kernel32.dll In _win_release_screen_block at address 3A Within file CLEARWIN64.DLL Within file Hstinpal64.exe in INTRO at address 7d6 in HSTINP at address f5

RAX = 0000000000000000 RBX = 00000009fffffff0 RCX = 0000000000090000 RDX = 0000000000000000 RBP = 0000000a00000000 RSI = 0000000000000000 RDI = 0000000000000000 RSP = 000000000259ef30 R8 = 0000000a00000000 R9 = 000007fee213c440 R10 = 00000000043e1300 R11 = 0000000000000000 R12 = 0000000000090000 R13 = 0000000000000071 R14 = 000000000000001c R15 = 000000000000020a

76d4d1e9) cmp_b [f+RBX],5

Not exactly the same as the one I posted yesterday, but still an Access Violation. I would love to send you my code, but the total program consists of almost 70 F95 files. I think that I have narrowd the problem down to one F95 file and 4 MOD files but I'm testing the scripts in alphabetic order...

What is the best way to send you my code? Copy and paste them on the forum, or add a link where they can be downloaded from.

Nick

DBOS.INS comes after INCLUDE thus:

INCLUDE <DBOS.INS>

release_screen_block@ takes one argument and this should be a 64 bit integer for 64 bit mode. FTN95 has the kind value 7 for variables that are 32 bit integers in 32 bit mode and 64 bit integers in 64 bit mode.

Concerning sending the code, it should be sufficient to isolate the winio@ sequence that causes the crash and post it here. Just make sure that the variables are clearly typed and have any necessary initial values.

Paul, Changing INTEGER to INTEGER (kind=7) for the release_screen_block@ did work! No longer an access violation error if is use the EXE. Some other problems did occur but I will try to solve them myself first.

If I compile the problem file with /CHECK, I still get the access violation error. So I will avoid using the /CHECK statement.

In the program are a lot of variables defind as INTEGER, should I replace them by INTEGER(KIND=7)

Nick

You can use /CHECK provided that you also use /INHIBIT_CHECK 16. It is section 16 of /CHECK that is causing the failure with your particular winio@ calls.

INTEGER(7) should only be used with certain integers. Details are provided in the help instructions. Basically it is for integers that correspond to a Microsoft HANDLE type. This is void* type in the C language and is a C pointer, in other words, an address so is 32 bits or 64 bits depending on the mode.