sdbg PROBLEM

After installing latest 8.80 i get strange thing: simple programs work with the debugger but all my major very different codes work OK without debugger but get this immediately when i invoke them via debugger:

Added to FTN95 folder new SDBG64 with the latest beta Trace option (size 2,135,040) which worked OK with older pre-880 compiler and it also works with the simple demos but it does not work with my major larger codes

Returned temporally back to older compiler pre-8.80 version (by just renaming FTN95 folders. This suggests that something is wrong with the new installation specifically related to the debugger )

/* Worst day today, third such devilry for a day. Two other related to still not resolved abrupt crashes of my PC (always when a lot of programs are loaded)

Dan,

Perhaps you need to rebuild your .exe and .dll's with the new Ver 8.80 compiler (while retaining your old versions in an alternative path for recovery)

Is your code compiled with a debug option (like /debug or /check)?

Robert, Here is my BAT file. I used no second arguments added to the BAT when executed it so that compilation goes automatically to the first (called DEBUG ) compilation option

if (%1)==(n)      goto nocheck
if (%1)==(N)      goto nocheck 

if (%1)==(o)      goto noch_opt
if (%1)==(O)      goto noch_opt

if (%1)==(nn)     goto nocheck2
if (%1)==(NN)     goto nocheck2

if (%1)==(oo)     goto noch_opt
if (%1)==(OO)     goto noch_opt
if (%1)==(O)      goto noch_opt
if (%1)==(o)      goto noch_opt

if (%1)==(z)      goto Z 
if (%1)==(Z)      goto Z

if (%1)==(g)      goto graphics


rem.............. DEBUG .........
del Postpic6432F.exe
del Postpic3264.obj
del PostPgr.obj
del *.mod
ftn95 radexkk.for /lis /dump /win /64 /undef /free /err /set_error_level error 298  /no_truncate /message_set_to_error 684   >_aradexkk
ftn95 Postpic3264.for /dump /64 /full_debug /win   /undef /check /check_winio /free /err /set_error_level error 298  /no_truncate /message_set_to_error 684    >_aFTN95___
ftn95 PostPgr.for  /dump /win /64 /debug /undef /check /check_winio /inhibit_check 16 /err /set_error_level error 298            >_aFTN95ogl___
rem ftn95 PostPgr.for /64 /debug /inhibit_check 16 /err /set_error_level error 298 >aFTN95ogl___
ftn95 Iam64bit.for /64 /free
src /r PostPICrc.rc                                                                          >_aRc
slink64  Postpic3264.obj PostPgr.obj PostPICrc.res Iam64bit.obj  /file:Postpic6432F.exe      >_aLink___
rem slink64 postpic.inf >_aLlink

rem rem slink postpic.obj PostPgr.obj SIMPLE.DLL               >_aLink___
rem if (%1)==(s)     goto SDBG
rem if (%1)==(S)     goto SDBG
rem postpic.exe
sdbg64 Postpic6432F.exe
goto end 

rem..............CHECK Graphics .........
:graphics
del Postpic6432nn.exe
del Postpic3264.obj
del PostPgr.obj
del *.mod
re ftn95 radexkk.for  /64 /free /nocheck /err /set_error_level error 298  /no_truncate   >_aradexkk
ftn95 radexkk.for /win /64 /free /err /set_error_level error 298  /no_truncate /message_set_to_error 684   >_aradexkk
ftn95 Postpic3264.for /64 /free /err /set_error_level error 298  /no_truncate            >_aFTN95___
ftn95 PostPgr.for  /64 /debug /check /undef /inhibit_check 16  /err /set_error_level error 298              >_aFTN95ogl___
ftn95 Iam64bit.for /64   /free
src /r PostPICrc.rc                                                                      >_a_rc
slink64  Postpic3264.obj PostPgr.obj PostPICrc.res Iam64bit.obj /file:Postpic6432gu.exe  >_alink___
goto end


rem..............NOCHECK .........
:nocheck
del Postpic6432n.exe
del Postpic3264.obj
del PostPgr.obj
del *.mod
ftn95 radexkk.for  /64 /free /nocheck /err /set_error_level error 298  /no_truncate    >_aradexkk
ftn95 Postpic3264.for /64 /free /err /set_error_level error 298  /no_truncate          >_aFTN95___
ftn95 PostPgr.for /64       /err /set_error_level error 298                            >_aFTN95ogl___
ftn95 Iam64bit.for /64 /free
src /r PostPICrc.rc                                                                    >_a_rc
slink64  Postpic3264.obj PostPgr.obj PostPICrc.res Iam64bit.obj /file:Postpic6432n.exe >_alink___
Postpic6432n.exe
goto end


:end

Version 8.80 dynamically allocates common blocks as they are used in 64-bits. sdbg64 needs to know where they are so that it can let this dynamic allocation complete. This looks like that is not happening correctly. Presumably an older sdbg64 (8.70 for example) produces the same effect.

John, The BAT file rebuilds everything. If not use SDBG64 all works OK. Based on Robert's comment, either you do not use SDBG or do not use COMMON blocks 😃. I still use them but less and less. And use them even inside modules just automatically often without any reason (taking them without modification from older codes which do approximately the same functions as new codes ) since compiler allows that and does not complain

Dan,

Your batch file shows compilation commands for some files such as Iam64bit.for without /undef, whereas you do use /undef for others.

This, by itself, need not be of concern, but if an EXE is built out of OBJ files built with a mix of /undef and no /undef, problems could occur. This may be one cause of odd behaviour of the program when run from SDBG.

You are generally right but in my case here is the whole text of this subroutine

	Subroutine prog32or64bit (k64bit)
	k64bit = 1 
	end

This was done in early years of 64bits when i did not know how to detect if program is compiled as 64 or 32 bit one

That subroutine has, by itself, no need for /undef because it has only one variable and one executable statement that sets a value into that variable.

However, most Fortran compilers that support checking for undefined variables have a requirement that all the sources be compiled with /undef, if a single portion is compiled with /undef.

The consequences of our ignoring this requirement are not stated, so anything can happen. You have nothing to lose by adding /undef to all the compile commands in your batch file.

I got a similar 'Access Violation' error with FTN95 /64 /check Ver 8.80.0. Below is a simpler example that compiles, and reports the error, but basically I incorrectly used an integer variable argument as an array name, which I think was interpreted as an external function.
/CHECK or /DEBUG did not report a problem with the usage.

  module data_info
    integer :: use_array(100)
  end module data_info

  use data_info
    integer :: num, thing_type

    use_array = 1
    num = 2
    thing_type = 4

    call add_thing ( num, thing_type )
    write ( *,*) use_array(num)
    end

   subroutine add_thing ( num, thing_type )
    use data_info  ! use_array is defined
    
    integer*4 :: num, thing_type
!...
     use_array(num) = thing_type(num)      ! incorrect use of variable thing_type > assumed was an external function
!...
   end subroutine add_thing

This appears to reproduce the error, with no compile error report

Update, The main problem with this error was the lack of information; no code line number or call stack. In the main large program, there would have been a significant call stack, although I had screen output > trace.log. The error actually occurred after a lot of calculation, but with screen output > trace.log, it looked instantaneous.

I was confronted with Access Violation at address ... then 'Within file xxx.exe'. (In a program of mine !! 😃

With /debug or /check I have become lazy and expect a code line address!

On review, the error message is different to Dan's, but the brevity is similar.

Hope this example helps.

The compiler should be able to catch this error (scalar variable of known type followed by subscript expression within parentheses) at compile time.

Here is a fleshed out version:

module data_info
   integer :: use_array(100)
end module data_info

program jcx
   use data_info
   integer :: num, thing_type

   use_array = 1
   num = 2
   thing_type = 4

   call add_thing ( num, thing_type )
   write ( *,*) use_array(num)
end program jcx

subroutine add_thing ( num, thing_type )
   use data_info  ! use_array is defined
   integer*4 :: num, thing_type
!...
     use_array(num) = thing_type(num)      ! incorrect use of variable thing_type > assumed was an external function
!...
end subroutine add_thing

Gfortran says:

jcx.f90:13:25:

   13 |    call add_thing ( num, thing_type )
      |                         1
Error: Expected a procedure for argument 'thing_type' at (1)

Intel Fortran gives a similar error message when the /warn:all option is used to compile.

Thanks. I have made a note of this.

The original issue is now fixed and a new sdbg64 can be downloaded from the usual place

Thanks, all works OK now

In future the program posted by mecej4 will produce a compile time warning when compiled with FTN95.