forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Acces Violation: Clearwin64

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
NickBuik



Joined: 20 Sep 2017
Posts: 3

PostPosted: Wed Sep 20, 2017 8:27 pm    Post subject: Acces Violation: Clearwin64 Reply with quote

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.
Code:

      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?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 732

PostPosted: Wed Sep 20, 2017 9:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1774
Location: Sydney

PostPosted: Thu Sep 21, 2017 1:59 am    Post subject: Reply with quote

You should change windows handles to integer*8 or integer(7). Clearwin "handles" can remain as integer*4.
Providing an integer*8 size handle when only integer*4 is required should not cause a problem, but returning an integer*4 could have a problem. Providing an integer*4, when an integer*8 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 real*4 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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4919
Location: Salford, UK

PostPosted: Thu Sep 21, 2017 7:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
NickBuik



Joined: 20 Sep 2017
Posts: 3

PostPosted: Thu Sep 21, 2017 9:15 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4919
Location: Salford, UK

PostPosted: Thu Sep 21, 2017 9:34 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
NickBuik



Joined: 20 Sep 2017
Posts: 3

PostPosted: Thu Sep 21, 2017 10:03 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 4919
Location: Salford, UK

PostPosted: Thu Sep 21, 2017 11:25 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group