Strange behaviour of app depending on environment???

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 REAL8 and II is of type INTEGER4.

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

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

Regards, Dietmar

Here is a code example for the phenomenon mentioned.

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, INTEGER4 or INTEGER8?
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

Here is a quick and incomplete answer to your questions.

I think the code can be reduced to...

      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?

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.

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

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.

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

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

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

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

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

Paul,

I have added your code to my application code, here is the new 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

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.

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.

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

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.

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.

This work is still ongoing but, for me, the version of ClearWin64.dll in the last full release works OK with Windows 7. So, if you are not dependent on subsequent updates, you could use this version for now.

Dietmar

I now have a build of clearwin64.dll that runs OK on my Windows 7 machine. A new set of DLLs will be available shortly.

Dietmar

Please see...

http://forums.silverfrost.com/viewtopic.php?p=22114#22114

Paul,

the new dlls from the download link work ok on both the PC having produced the exception and on my own PC 😃

Great work. Thanks a lot.

Regards, Dietmar