version 9.04

I have just loaded the various new DLLs and lib files for version 9.04. After recompiling my application, the program hangs at start up. It's about 160,000 lines of code, and I do not have the time to go through and try to find the problem. Based purely on the point at which the programme hangs, there may be a problem trying to load the background colour (%bg in ClearWin+). I have had to revert to version 9.00.

Simon

Have you used v9.04 of FTN95 with the new DLLs?

Hi Paul, I believe so - I copied everything from the FTN95, DLL, and Plato links into the directory where I have FTN95 installed.

Simon

Is there no trace back to give a hint as to what went wrong? Try using the debugging options and rebuild everything. On the other hand, if you are happy using v9.0 then it won't be long before we issue a full release.

Hi Paul,

I am typically using Plato for Ver 9.03.0.0 with options of /64 /check. I build and run using a .bat file.

set options=/64 /check

del manage_shares_error.log

now > manage_shares.log

ftn95 module_ver_g               %options%  >> manage_shares.log
ftn95 module_trans               %options%  >> manage_shares.log
...
ftn95 report_holding             %options%  >> manage_shares.log

del manage_shares.exe

slink64 @load.txt                           >> manage_shares.log

For example if I have a format / data mis-match (mix integer variable with real format) I don't get a traceback or tidy error report, but an access violation pop up.

Silverfrost 64-bit exception report on E:\share_info\manage_shares.exe  Mon Mar 16 00:51:42 1970


Access violation (c0000005) at address 7ffe5b0bda73

Within file CLEARWIN64.DLL
In  _winio at address 9B4
In  _system_exception_handler(<ptr>structÄ_EXCEPTION_POINTERS) at address D95
Within file SALFLIBC64.DLL
in __system_exception_handler(<ptr>structÄ_EXCEPTION_POINTERS) at address d95
Within file ntdll.dll
In  RtlRaiseException at address 2A6
In  KiUserExceptionDispatcher at address 2E
In  ReportErrorString at address 49
Within file SALFLIBC64.DLL
in ReportErrorString@ at address 49
Within file CLEARWIN64.DLL
In  _get_runerrs at address 24C
In  _SetMaximumIOBufferSize at address 12D
In  _SetMaximumIOBufferSize at address 71C3


RAX = 0000000000000000   RBX = 0000000000005753   RCX = 00000000024fc688   RDX = 000000000b1cca30
RBP = 00000000024fc619   RSI = 0000000000000000   RDI = 00000000ffffffff   RSP = 00000000024fb810
R8  = 0000000000000001   R9  = 00000000ffffffff   R10 = 0000000000007777   R11 = 00000000024fc558
R12 = ffffffffffffffff   R13 = 0000000000000000   R14 = 00000000024fc5e0   R15 = 0000000000000000

7ffe5b0bda73) cmp_b       [RAX+R15],RSI

Any ideas why the cryptic response ?

I may need a reset with a complete rebuild of Ver 9.04 ?

John

I don't have any immediate insights into this failure. I will probably need a reproducer of some kind. I also don't know if v9.04 will help in this case.

Paul,

This may be related to the FTN95 files are not all compatible, but this example produces a similar error report on my install.

! reproducer for formast data mismatch

   character*20 :: warn_msg = ' warning of error'
   character*11 :: date     = '19/08/2024 '
   integer      :: lpart = 11, npart = 15

    write ( *,61)  warn_msg // date,    &
              ' Change in last 60 days : check participating count', lpart, npart    !  , holdings(ih)%avail_shares
    61    format ( 1x,a,a,f8.0,3i8 )
   end

ftn95 trace_back /check /64 /link

Silverfrost 64-bit exception report on E:\share_info\trace_back.exe  Tue Mar 17 13:16:01 1970


Access violation (c0000005) at address 7ffe5b0bda73

Within file CLEARWIN64.DLL
In  _winio at address 9B4
In  _system_exception_handler(<ptr>structÄ_EXCEPTION_POINTERS) at address D95
Within file SALFLIBC64.DLL
in __system_exception_handler(<ptr>structÄ_EXCEPTION_POINTERS) at address d95
Within file ntdll.dll
In  RtlRaiseException at address 2A6
In  KiUserExceptionDispatcher at address 2E
In  ReportErrorString at address 49
Within file SALFLIBC64.DLL
in ReportErrorString@ at address 49
Within file CLEARWIN64.DLL
In  _get_runerrs at address 24C
In  _SetMaximumIOBufferSize at address 12D
In  _SetMaximumIOBufferSize at address 71C3


RAX = 0000000000000000   RBX = 0000000000005753   RCX = 00000000023ffa08   RDX = 000000000b65d280
RBP = 00000000023ff999   RSI = 0000000000000000   RDI = 00000000ffffffff   RSP = 00000000023feb90
R8  = 0000000000000001   R9  = 00000000ffffffff   R10 = 0000000000007777   R11 = 00000000023ff8d8
R12 = ffffffffffffffff   R13 = 0000000000000000   R14 = 00000000023ff960   R15 = 0000000000000000

7ffe5b0bda73) cmp_b       [RAX+R15],RSI

My ftn95 version 9.03.0.0 files are listed in https://forums.silverfrost.com/Forum/Topic/4471

This reproducer build does not select clearwin ?

John

Your sample code works for me. The traceback uses winio calls and that is where the failure occurs.

So there does appear to be some incompatibility in the v9.03 files that you are currently using.

The v9.04 files are for FTN95 and all the DLLs (SLINK64 ought to be OK but at worst I may need to upload a rebuild. Plato is largely independent.).

You could backup what you know works and try v9.04.

Thanks Paul, I will generate a Ver 9.04, see how it goes and report back.

Hi Paul,

I downloaded the Ver 9.04 update files from the support links. I updated 11 files.

I compiles and ran with 'ftn95 /lgo' and got a similar resp;onse to ver 9.03, giving a Format mismatch report.

I compiles and ran with 'ftn95 /64 /lgo' and got a different response !

First, I got the Win 10 virus warning, that the .exe had to be checked. The second time, I did not get the virus warning, but then got the similar access violation report.

This report ( like Ver9.03 ) references ntdll.dll which is not in my silverfrost > FTN(%_9.04F directory.

I shall next download the latest full version available and report back.

It is being to look like we will need to provide a rebuilt SLINK64 with the v9.04 download. If anyone has successfully installed and used the v9.04 update then please let me know.

Paul,

I have now downloaded the Ver 9.00 (Nov-23) ftn95_update.exe and have done a clean build. This version gives similar results to Ver 9.04.

I am using Windows 10 Pro, version 22H2

Using the small reproducer I posted yesterday, I tested both 32-bit and 64-bit.

FTN95 32-bit works giving format data mismatch reported in a pop-up box.

FTN95 /64 /LGO still gives an access violation error report, no traceback. (I did not get the Microsoft Defender message)

Silverfrost 64-bit exception report on E:\f95_test\lgotemp@.exe  Wed Mar 25 03:18:45 1970


Access violation (c0000005) at address 7fffb53f5c93

Within file CLEARWIN64.DLL
In  _winio at address 9EF
In  _system_exception_handler(<ptr>structÄ_EXCEPTION_POINTERS) at address D95
Within file SALFLIBC64.DLL
in __system_exception_handler(<ptr>structÄ_EXCEPTION_POINTERS) at address d95
Within file ntdll.dll
In  RtlRaiseException at address 2A6
In  KiUserExceptionDispatcher at address 2E
In  ReportErrorString at address 49
Within file SALFLIBC64.DLL
in ReportErrorString@ at address 49
Within file CLEARWIN64.DLL
In  _get_runerrs at address 24C
In  _SetMaximumIOBufferSize at address 12D
In  _SetMaximumIOBufferSize at address 6F38


RAX = 0000000000000000   RBX = 00000000ffffffff   RCX = 00000000023ff9c8   RDX = 000000000a7bbaf0
RBP = 00000000023ff959   RSI = 0000000000000000   RDI = ffffffffffffffff   RSP = 00000000023fecd0
R8  = 0000000000000010   R9  = 0000000000000000   R10 = 0000000000007777   R11 = 00000000023ff898
R12 = 00000000023ff910   R13 = 0000000000000000   R14 = 00007fffb5350000   R15 = 0000000000000000

7fffb53f5c93) cmp_b       [RAX+RSI],0

For my larger program ( that can run in 32-bit or 64-bit) I do note that the 64-bit traceback does go back 10 levels but remains in the Silverfrost libraries. Is this possibly the correct response ? Unfortunately there is no indication of where the error originated.

Paul,

I have made some progress with my larger program (that consists of 20 .f90 files)

I tested my small reproducer with 'ftn95 trace_back /checkmate /64 /lgo' When it reached the Format/data mismatch, it poped up in sdbg64 and gave the required info.

This outcome can be reproduced using: ftn95 trace_back /checkmate /64 /link sdbg64 trace_back

However, If I use two commands: ftn95 trace_back /checkmate /64 /link trace_back

This produces the Access violation report. (this is the way I had typically tested programs)

So, now, rather than running the larger program, if I use 'sdbg64 program' I get a better result. In the build and run batch file, this now gives a stop at the correct place and gives the error information required.

But, just running the program that has been built with /64 /check does not give a clear error report.

Thanks John

I am assuming that it is a SLINK64 issue and will investigate further.

Paul,

Thanks for investigating this minor problem that has been annoying me for months. You could confirm you have the same problem I am seeing by using the small reproducer above as trace_back.f90 and trying:

'ftn95 trace_back /64 /check /lgo' ( this should correctly report the error in SDBG64 )

'ftn95 trace_back /64 /check /link' 'sdbg64 trace_back' ( this should correctly report the error in SDBG64 )

'trace_back' ( this should report an access violation )

My test .bat file is (set_f95 selects F95 version in path):

call set_f95 %1

del trace_back.exe
del trace_back.obj

ftn95 trace_back /64 /check /lgo

del trace_back.exe
del trace_back.obj

ftn95 trace_back /64 /check /link

trace_back

sdbg64 trace_back

Two questions:

1. I normally use 'trace_back > trace_back.log' but changing to 'sdbg64 trace_back > trace_back.log' does not appear to send standard output to trace_back.log. Is there a way to achieve this ?

2. I am puzzled by the appearence of 'ntdll.dll' in the trace back report. Any idea what this is ?

My copies of Ver 9.00, 9.03 and 9.04 all have this problem. Also versions 8.64, 8.74, 8.80, 8.92 and 8.97.2 reproduce the problem, so quite a long time (unless my test approach is wrong. I open a new command window with each test )

John

I don't experience the access violation when running your sample. So there appears to be some incompatiblity in the current download for v9.04. As you say, the access violation occurs when there is a runtime error and during the time when the traceback dialog is displayed.

1. I don't know how to redirect the output when running SDBG64.

2. ntdll.dll is a Microsoft system DLL. It is not scanned by SLINK64 and is presumably accessed from another Microsoft DLL such as user32.dll.

I don't experience the access violation when running your sample

So you do not get the failure I am seeing ? That is a worry. Could it be related to Win 10 and ntdll.dll ? ntdll.dll is mentioned in the access violation failure trace back ?

It is now more of interest as 'sdbg64 program' overcomes the error identifying problems when there is a program error, such as format data mismatch.

John

That's right. I can reproduce your experience but not the access violation.

I think that it is more likely to be a problem with SLINK64 and I am working on it.

Work on this issue is on going.

As a work-around, when the traceback dialog fails to run, a shortened trace message can be diverted to the command line by setting the environment variable...

set SALFENVAR=kill_dialogbox

I have run into this problem (Slink64 3.10 reports access violation). If the output EXE file is named explicitly with the linker's /file:<name>.exe'option, the problem is not seen!