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 

sdbg PROBLEM

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2476
Location: South Pole, Antarctica

PostPosted: Fri Aug 27, 2021 2:52 am    Post subject: sdbg PROBLEM Reply with quote

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)
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2351
Location: Sydney

PostPosted: Fri Aug 27, 2021 7:28 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 390
Location: Manchester

PostPosted: Fri Aug 27, 2021 11:51 am    Post subject: Reply with quote

Is your code compiled with a debug option (like /debug or /check)?
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2476
Location: South Pole, Antarctica

PostPosted: Fri Aug 27, 2021 5:20 pm    Post subject: Reply with quote

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
Code:
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
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 390
Location: Manchester

PostPosted: Fri Aug 27, 2021 9:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2476
Location: South Pole, Antarctica

PostPosted: Sun Aug 29, 2021 8:41 pm    Post subject: Reply with quote

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 Smile. 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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1580

PostPosted: Mon Aug 30, 2021 1:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2476
Location: South Pole, Antarctica

PostPosted: Tue Aug 31, 2021 3:42 am    Post subject: Reply with quote

You are generally right but in my case here is the whole text of this subroutine
Code:
   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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1580

PostPosted: Tue Aug 31, 2021 11:01 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2351
Location: Sydney

PostPosted: Fri Oct 29, 2021 8:37 am    Post subject: Reply with quote

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.

Code:
  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.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1580

PostPosted: Fri Oct 29, 2021 12:43 pm    Post subject: Reply with quote

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:

Code:
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:

Code:
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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Oct 29, 2021 3:16 pm    Post subject: Reply with quote

Thanks. I have made a note of this.
Back to top
View user's profile Send private message AIM Address
silverfrost
Site Admin


Joined: 29 Nov 2006
Posts: 185
Location: Manchester

PostPosted: Tue Nov 02, 2021 6:11 pm    Post subject: Reply with quote

The original issue is now fixed and a new sdbg64 can be downloaded from the usual place
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2476
Location: South Pole, Antarctica

PostPosted: Wed Nov 03, 2021 3:35 am    Post subject: Reply with quote

Thanks, all works OK now
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Nov 17, 2021 11:13 am    Post subject: Reply with quote

In future the program posted by mecej4 will produce a compile time warning when compiled with FTN95.
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
Page 1 of 1

 
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