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 

Difference in behaviour between 32/64 bit with fopen

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Tue Apr 14, 2020 7:41 pm    Post subject: Difference in behaviour between 32/64 bit with fopen Reply with quote

The following C++ code (called from Fortran, all compiled with silverfrost) opens a file under 32 bit in read mode but fails silently to open the same file in 64 bit.

f1 = fopen( input_filename, "r" );

64 bit does get a file handle but does not open it for read (all attributes are cleared when inspected with handle.exe from sysinternals). This file handle cannot then be closed which causes more problems further on.

32 bit obtains a read handle fine (handle.exe reports an R flag for read which is correct).

I have checked;
1) Latest 8.61 version of compiler.
2) Both 32 bit DLLs (salflibc64.dll, clearwin64.dll) loaded from the 8.61 compiler path and both are version 22.2.3.15.
3) Included /checkmate in the build process, nothing reported.
4) Output the input_filename char buffer to a message box, appears the same in 32 and 64.
5) The file attributes are checked by pausing the debugger immediately after fopen to ensure no other code is closing or interfering with the handle.

The next step is to isolate it to a tiny bit of Fortran and C++ code but this will take me an hour or so. Does this ring any bells for anyone? I may also try stepping back 8.5 as I did not receive bug reports on this code until the upgrade to 8.61.

Regards

Ryan
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Apr 14, 2020 8:44 pm    Post subject: Reply with quote

Ryan

fopens was added to salflibc64.dll at v8.60 and fopen became a special case of fopens. So it is possible that there is a regression.

You may not be able to go back to an earlier version of salflibc64.dll on its own.

I will aim to look into this. In the mean time you could either try fopens or go back wholesale to an eariler version.
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Tue Apr 14, 2020 8:50 pm    Post subject: Reply with quote

Thank you Paul.

Do you have an example or signature for fopens? I'm guessing it is a secure version so the parameters will probably have changed.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Wed Apr 15, 2020 12:55 am    Post subject: Reply with quote

Please see https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-s-wfopen-s?view=vs-2019 . Many of the CRT functions with _s in their names are secure versions of the traditional functions that were present in older CRTs or Unix.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 15, 2020 8:28 am    Post subject: Reply with quote

Ryan

I should have written _fsopen which has sharing options but I aim to look at this issue later this morning if you can wait.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 15, 2020 11:01 am    Post subject: Reply with quote

Ryan

fopen works for me in a 64 bit C program. You say that you make the call from Fortran code. How do you declare fopen in Fortran?
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 15, 2020 11:18 am    Post subject: Reply with quote

fopen works for me in an FTN95 program. Here is my sample code:

Code:
program main
   integer(7) tfile;
   character(2048) buffer
   integer nread,r
   C_EXTERNAL fopen  'fopen' (INSTRING,INSTRING):INTEGER(7)
   C_EXTERNAL fread  'fread' (REF,VAL,VAL,VAL):INTEGER*4
   C_EXTERNAL fclose 'fclose'(VAL):INTEGER*4
   tfile = fopen("c:\techsupport\ls1.f95","r")
   nread = fread(buffer, 1, 2048, tfile);
   r =  fclose(tfile);
   print*,tfile,nread,r
   print*, buffer(1:nread)
end program
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Wed Apr 15, 2020 2:00 pm    Post subject: Reply with quote

What I meant by 'called from Fortran' is that the Fortran code calls a routine in C which then calls fopen.

This uses the definition from include\stdio.h
FILE *fopen(const char *filename, const char *mode);

Sorry for not mentioning this, the read works which may be why your code seems OK. I've checked a 32 and 64 bit copy of your code and the 64 bit one does not show the correct correct file access attributes in the handle.

I placed a pause statement after fopen in your code, ran it and then used 'handle -p procname'. In my case I got this for 32 bit;

290: File (RW-) D:\3d.txt

But for 64 bit I received;

B4: File (---) D:\3d.txt

All other file flags (the executable, current folder and winsxs assemblies) loaded with attributes set for both 32/64, for example;

AC: File (RW-) C:\Windows\WinSxS*****

I may be me barking up the wrong tree, I'm not sure. This does seem to be the source of a file access bug I am trying to track down.

I'll try the 8.5 compiler and DLLs now.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 15, 2020 3:00 pm    Post subject: Reply with quote

Ryan

If you call fopen in "r" mode and fread works OK what is the problem?
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Wed Apr 15, 2020 3:05 pm    Post subject: Reply with quote

Later on in the code the file is closed, then opened again for write.

In 32 bit this works.

In 64 bit the file handle is not released and the open for write fails.

Using procmon.exe I can see the same open, read, close, open steps for both executables but the 64 bit fails due to sharing violation.

Since I'm monitoring the events at a low level I can see that the same API calls are being made, the only difference I can see is the access flags not being set correctly.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 15, 2020 3:15 pm    Post subject: Reply with quote

Quote:
In 64 bit the file handle is not released and the open for write fails.


Is that because you do not call fclose or because of some other fault?
Back to top
View user's profile Send private message AIM Address
Ryan



Joined: 25 Feb 2016
Posts: 110

PostPosted: Wed Apr 15, 2020 3:22 pm    Post subject: Reply with quote

It's the same code in both situations and they both call fclose before attempting to open it again.

It could be me, but at the moment the only thing I can see different is the file attributes not being set in the 64 bit version. I see the same issue with the code you sent.

I can see the fclose going through when monitoring the process and it allegedly succeeds. My guess is that the open does not work the same in 64 bit.

I'm wary of wasting your time if it is my fault, but I'm running out of ideas. I have tried 8.50 and that is the same but that does not rule any bugs in or out. I'll try the other fsopen later.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 15, 2020 5:22 pm    Post subject: Reply with quote

I still don't understand the problem. Here is my new sample that works OK for me.

Code:
program main
   integer(7) tfile;
   character(2048) buffer
   integer nread,r,nwrite
   C_EXTERNAL fopen  'fopen' (INSTRING,INSTRING):INTEGER(7)
   C_EXTERNAL fread  'fread' (REF,VAL,VAL,VAL):INTEGER*4
   C_EXTERNAL fwrite 'fwrite'(REF,VAL,VAL,VAL):INTEGER*4
   C_EXTERNAL fclose 'fclose'(VAL):INTEGER*4
   tfile = fopen("c:\techsupport\ls1.f95","r")
   nread = fread(buffer, 1, 2048, tfile);
   r =  fclose(tfile);
   print*,tfile,nread,r
!  print*, buffer(1:nread)
   tfile = fopen("c:\techsupport\copy.f95","w")
   nwrite = fwrite(buffer,1,nread,tfile);
   r = fclose(tfile);
   print*,tfile,nwrite,r
end program


You need the "w" mode for fwrite. You could use "rw" on the first fopen and omit the middle fclose if you are writing back to the same file.

If you want me to look further into this then can you provide a demo program.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit 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