| View previous topic :: View next topic |
| Author |
Message |
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
 Posted: Fri Jun 09, 2017 1:29 pm Post subject: 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 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 |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
| Posted: Fri Jun 09, 2017 3:10 pm Post subject: |
|
|
Meanwhile I hope to be able to provide a code example for this phenomenon next Monday.
Regards,
Dietmar |
|
| Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
| Posted: Mon Jun 12, 2017 4:01 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Mon Jun 12, 2017 5:24 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Mon Jun 12, 2017 10:24 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Tue Jun 13, 2017 7:50 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
| Posted: Tue Jun 13, 2017 8:57 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
| Posted: Tue Jun 13, 2017 9:34 am Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Tue Jun 13, 2017 10:40 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
| Posted: Tue Jun 13, 2017 11:49 am Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Tue Jun 13, 2017 1:25 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Tue Jun 13, 2017 1:40 pm Post subject: |
|
|
| 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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013
Posts: 279
|
| Posted: Tue Jun 13, 2017 2:11 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Tue Jun 13, 2017 4:19 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8037
Location: Salford, UK
|
| Posted: Wed Jun 14, 2017 9:24 am Post subject: |
|
|
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 |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
