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 

Strange behaviour of app depending on environment???
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri Jun 09, 2017 1:29 pm    Post subject: Strange behaviour of app depending on environment??? Reply with quote

We have built a 64 bit GUI application named p0918w_64.exe by means of ftn95, Version 8.10 which runs on
several PCs. However, there is 1 PC (running Windows 7, 64 Bit) where the application does not work and results in the Silverfrost exception report

Attempt to execute illegal instruction c000001d at address 7fede0a87f0
Within file CLEARWIN64.DLL
In DANINT$$ at address 0
Within file p0918w_64.exe
in INWAND at address 27b
...

p0918w_64.exe, clearwin64.dll and salflibc64.dll are located in a directory, say start_dir, located on a shared drive.
p0918w_64.exe is started from start_dir for each of the PCs in question.

The ressource monitor shows that dlls clearwin64.dll and salflibc64.dll are loaded from start_dir in all cases tested.

The Fortran call of INWAND which causes the exception is

II=INTL(DNINT(RR))

where RR is of type REAL*8 and II is of type INTEGER*4.

The corresponding 32 bit application runs successfully on the PC for which the error occurs for the 64 bit version.

Does anyone have an idea why this could happen?
I have no idea how to break this down to a small application which I could send to you.

Regards,
Dietmar
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri Jun 09, 2017 3:10 pm    Post subject: Reply with quote

Meanwhile I hope to be able to provide a code example for this phenomenon next Monday.

Regards,
Dietmar
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Mon Jun 12, 2017 4:01 pm    Post subject: Reply with quote

Here is a code example for the phenomenon mentioned.
Code:

character*10 myc
      INTEGER*4 II

      REAL*8 MYRR,MYDNINT
      REAL*8 DNINT
     
      MYRR=0
#if 0     
      II=INTL(DNINT(MYRR))
#else
      MYDNINT=DNINT(MYRR)
      write(2,*) 'MYDNINT=',MYDNINT
      II=INTL(MYDNINT)
      write(2,*) 'II=',II
#endif
     
      write(2,'(A)') 'Enter any key to quit'
      read(1,'(A)') myc
     
      end

I compiled this code (named intl_dnint.for) by command
ftn95 intl_dnint.for /undef /cfpp /64 /link
and copied it to a shared drive. On 1 PC the executable intl_dnint.exe crashed with the exception mentioned above. No write statement is executed in this case.
On several other PCs this code works and produces the write statements expected.

In this context I have some questions.

1. If I had not defined intrinsic function dnint to REAL*8 in the code, what would have been the type of dnint?
2. What is the type returned by function INTL, INTEGER*4 or INTEGER*8?
3. Is there any functionality to list the dlls loaded by a fortran application from within the application's code?

Thanks in advance for any help.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Jun 12, 2017 5:24 pm    Post subject: Reply with quote

Here is a quick and incomplete answer to your questions.

I think the code can be reduced to...

Code:
      INTEGER II
      REAL*8 MYRR,MYDNINT
      MYRR = 0d0
      MYDNINT = ANINT(MYRR)
      II = MYDNINT
      write(2,*) 'MYDNINT=', MYDNINT
      write(2,*) 'II     =',II
      END


ANINT is the Fortran standard form of the function. When it has one argument its return value has the same type and kind as the argument. When using ANINT you don't need to declare its return type and kind.

INTL is not needed in this program. It converts the argument to a 32 bit integer and this happens anyway. INT is the Fortran standard form of this function and (for a single argument) the return type is a integer with default integer kind.

How does this shortened program behave for you?
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: Mon Jun 12, 2017 10:24 pm    Post subject: Reply with quote

Listing the DLLs used from the Fortran code
---------------------------------------------------

I have had a brief look at this and I don't have a satisfactory answer at the moment. Here is some code that works up to a point but I can't see how to read the results into a file for processing. Normally I would add ">output.txt" to the command line but this does not work from a background command.

Code:
PROGRAM main
STDCALL GETCURRENTPROCESSID 'GetCurrentProcessId':INTEGER*4
INTEGER id,k,start_process@
CHARACTER command*80, val*8
id = GetCurrentProcessId()
WRITE(val, '(i8)') id
command = 'tasklist /FI "PID eq ' //trim(adjustl(val))//'" /FO list /M'
k = start_process@(command, "")
END
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: Tue Jun 13, 2017 7:50 am    Post subject: Reply with quote

Following on from my last post, CISSUE@ works better because it calls cmd.exe. So here is a way to programmatically get a list of DLLs.

Code:
PROGRAM main
STDCALL GetCurrentProcessId 'GetCurrentProcessId':INTEGER
INTEGER id
INTEGER*2 ic
CHARACTER(*),PARAMETER::resfile = "results.tmp"
CHARACTER command*80, val*8, line*80
id = GetCurrentProcessId()
WRITE(val, '(i8)') id
command = 'tasklist /FI "PID eq ' //trim(adjustl(val))//'" /FO list /M >'//resfile
CALL CISSUE@(command, ic)
OPEN(10,file=resfile)
do
  READ(10, '(A80)', end=100) line
  PRINT*, trim(line)
end do 
100 CLOSE(10)
CALL ERASE@(resfile,ic)
END
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 13, 2017 8:57 am    Post subject: Reply with quote

Paul,

thanks for your informations.

I tried the shortened program using ANINT, however, this did not help. On 1 PC it works ok, on another it again crashes with an exception report:

Attempt to execute illegal instruction (c000001d) at address 7fed6d387f0

Within clearwin64.dll
In DANINT$$ at address 0
Within file anint.exe
in main@ in line 4, at address 6b

Regards,
Dietmar
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 13, 2017 9:34 am    Post subject: Reply with quote

Paul,

I tried out the code you gave me for listing the dlls (second version). It works and lists the dlls, thanks for your info again.

Unfortunately it does not list the path of the dlls (especially of dll clearwin64.dll which I intended to print out from within an executable, e.g. intl_dnint.exe). And I did not find a way to get the dll paths by viewing the online help of the tasklist command.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jun 13, 2017 10:40 am    Post subject: Reply with quote

Dietmar

Does it fail on the first call into ClearWin84.dll? If it is the first call then maybe the DLL is not accessible in some way (however, you should get a clear message to this effect). DANINT$$ is a simple (one line) function in ClearWin64.dll. Its argument is passed by value and if there is a coding error then it should show up when used locally.

Here is some code to get information about ClearWin64.dll...

Code:
C_EXTERNAL GetLibraryVersionInfo@ '_GetLibraryVersionInfo'():STRING
C_EXTERNAL GetLibraryPath@        '_GetLibraryPath'():STRING
C_EXTERNAL GetLibraryDateInfo@    '_GetLibraryDateInfo'():STRING
CHARACTER str*256

  str = GetLibraryVersionInfo@()
  PRINT*, 'VERSION: ', trim(str)
  str = GetLibraryPath@()
  PRINT*, 'PATH   : ', trim(str)
  str = GetLibraryDateInfo@()
  PRINT*, 'DATE   : ', trim (str)

END
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 13, 2017 11:49 am    Post subject: Reply with quote

Paul,

I have added your code to my application code, here is the new code:
Code:

      INTEGER II
      REAL*8 MYRR,MYDNINT
      C_EXTERNAL GetLibraryVersionInfo@ '_GetLibraryVersionInfo'():STRING
      C_EXTERNAL GetLibraryPath@        '_GetLibraryPath'():STRING
      C_EXTERNAL GetLibraryDateInfo@    '_GetLibraryDateInfo'():STRING
      CHARACTER str*256

      str = GetLibraryVersionInfo@()
      PRINT*, 'VERSION: ', trim(str)
      str = GetLibraryPath@()
      PRINT*, 'PATH   : ', trim(str)
      str = GetLibraryDateInfo@()
      PRINT*, 'DATE   : ', trim (str)

      MYRR = 0d0
      MYDNINT = ANINT(MYRR)
      II = MYDNINT
      write(2,*) 'MYDNINT=', MYDNINT
      write(2,*) 'II     =',II
      END

The executable compiled prints out the library information in both the successful and the unsuccessful case (and this information is the same in both cases):
VERSION: 19.5.4.13
PATH : <start_dir of executable>\CLEARWIN64.DLL
DATE : 7:17:50 - 5:5:2017
. In the unsuccessful case (creating the exception) the write statements printing MYDNINT or II are not executed.

The sample I referred to in my previous post failed on the first call into CLEARWIN64.dll.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jun 13, 2017 1:25 pm    Post subject: Reply with quote

Dietmar

My current build of ClearWin64.dll uses msvcrt.dll and the version of msvcrt.dll on my Windows 7 machine is much older.

I will see if I can reproduce your error on that machine.
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: Tue Jun 13, 2017 1:40 pm    Post subject: Reply with quote

It does fail on my Windows 7 machine and I suspect that it a problem with msvcrt.dll compatibility but that's as far as I have got.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 13, 2017 2:11 pm    Post subject: Reply with quote

Paul,

meanwhile we found other CLEARWIN64 applications which crash on the special PC with an exception at the first call into clearwin64.dll.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jun 13, 2017 4:19 pm    Post subject: Reply with quote

Dietmar

I will take a look at it when I can but if it is a problem with msvcrt.dll then the solution will be for you to download and install a later version of msvcrt or alternatively for Silverfrost to release a version of ClearWin64.dll that has msvcrt embedded in the DLL.
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 Jun 14, 2017 9:24 am    Post subject: Reply with quote

Dietmar

I have not yet been able to fix this problem. It appears to occur randomly - not just for ANINT. I am assuming that the new ClearWin64.dll is not compatible with the old msvcrt.dll.

I haven't found a way to replace msvcrt.dll on a Windows 7 machine nor can I find a simple way to remove this dependency in ClearWin64.dll.

I think that the only way forward is to try to build a version of ClearWin64.dll on my Windows 7 machine but that will take time and may not solve the problem.
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
Goto page 1, 2  Next
Page 1 of 2

 
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