View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Fri Aug 27, 2021 2:52 am Post subject: 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) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Aug 27, 2021 7:28 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Robert
![](http://forums.silverfrost.com/images/avatars/141724757f4c9c04bd.jpg)
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Fri Aug 27, 2021 11:51 am Post subject: |
|
|
Is your code compiled with a debug option (like /debug or /check)? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Fri Aug 27, 2021 5:20 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Robert
![](http://forums.silverfrost.com/images/avatars/141724757f4c9c04bd.jpg)
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Fri Aug 27, 2021 9:22 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sun Aug 29, 2021 8:41 pm Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Aug 30, 2021 1:41 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Tue Aug 31, 2021 3:42 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Aug 31, 2021 11:01 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Oct 29, 2021 8:37 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Oct 29, 2021 12:43 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7926 Location: Salford, UK
|
Posted: Fri Oct 29, 2021 3:16 pm Post subject: |
|
|
Thanks. I have made a note of this. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
silverfrost Site Admin
![](http://forums.silverfrost.com/images/avatars/141724757f4c9c04bd.jpg)
Joined: 29 Nov 2006 Posts: 191 Location: Manchester
|
Posted: Tue Nov 02, 2021 6:11 pm Post subject: |
|
|
The original issue is now fixed and a new sdbg64 can be downloaded from the usual place |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Nov 03, 2021 3:35 am Post subject: |
|
|
Thanks, all works OK now |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7926 Location: Salford, UK
|
Posted: Wed Nov 17, 2021 11:13 am Post subject: |
|
|
In future the program posted by mecej4 will produce a compile time warning when compiled with FTN95. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|