View previous topic :: View next topic |
Author |
Message |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Jun 06, 2018 12:39 pm Post subject: |
|
|
Robert,
with version 8.30.2 of sdbg64 I now run into problems when opening some of the debugger's "Window" menu. When trying to debug
Code: |
integer*4 idum
idum=5
write(*,*) 'idum=',idum
end
|
(the example I mentioned above)
opening submenu "Variables" has no effect,
opening submenu "Common blocks" opens no window and makes sdbg64 hang.
Has anyone else observed similar problems with this version of sdbg64?
Regards,
Dietmar |
|
Back to top |
|
 |
Robert

Joined: 29 Nov 2006 Posts: 457 Location: Manchester
|
Posted: Thu Jun 07, 2018 8:01 am Post subject: |
|
|
Doesn't the variables window open automatically? |
|
Back to top |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 07, 2018 8:45 am Post subject: |
|
|
Robert,
no, the variables window does not open automatically.
The problem is even worse now.
After having started the sdbg64 debugger (version 8.30.2) once, the variables window did not open automatically.
The next start of sdbg64 did not even show the source window of the debuggee, this was the case for sdbg64 version 8.30.2, version 8.30.1 and 8.30.
I have no idea what might have happened with respect to my build/sdbg64 environment with respect to yesterday.
Regards,
Dietmar |
|
Back to top |
|
 |
Robert

Joined: 29 Nov 2006 Posts: 457 Location: Manchester
|
Posted: Thu Jun 07, 2018 8:50 am Post subject: |
|
|
It might we worth having a look at the sdbg64.ini file to see if it has any corrupted values in it. On my machine it is at:
C:\Users\Robert\AppData\Roaming |
|
Back to top |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 07, 2018 10:37 am Post subject: |
|
|
Robert,
thanks for the hint. I did not find any suspicious data in my current sdbg64.ini file, however, I overwrote it with a backup from 2017. This helped to be able to debug again and see windows
per default. Some observations:
1.
First line of file sdbg64.ini is
[Debugger-Win32]
which seems to be strange for a 64 bit debugger.
2.
Where do I find information about the semantic of sdbg64.ini?
3.
Some time ago I complained about not being able to see the version information window after having clicked menus "Help" and "About Debugger..." in sdbg64. This is still a problem and I wonder if this problem might be related to my sdbg64.ini file.
4.
To me it is unclear what caused the problem to the previous sdbg64.ini files which seemed to be wrong.
Regards,
Dietmar |
|
Back to top |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 07, 2018 11:47 am Post subject: |
|
|
Robert,
in connection with a problem previously mentioned I ran in another problem when trying to change an integer*8 variable from within sdbg64.
Code: |
integer*4 idum
integer*8 idum8
idum=5
idum8=4294967296
write(*,*) 'idum=',idum
write(*,*) 'idum8=',idum8
end
|
Now I stopped the debugger after the idum8 assignment and tried to change idum8 using the command tool of sdbg64 and command
; this resulted in value
Code: |
-3689348818177884159
|
for idum8 which was not what I expected.
By the way, it would be nice if I could have had the chance of copying the idum8 value to the clipboard from one of the windows displaying variable idum8 in sdbg64.
Regards,
Dietmar |
|
Back to top |
|
 |
Robert

Joined: 29 Nov 2006 Posts: 457 Location: Manchester
|
Posted: Fri Jun 08, 2018 4:52 pm Post subject: |
|
|
I have updated sdbg64 to handle the let statement with integer*8 variables. I have also added a Copy onto the context menu for the single line inspectors. |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Sun Jun 10, 2018 9:53 am Post subject: |
|
|
Robert, Thanks for 3 sec delay fix. Please look at other suggestions/problems of SDBG64 above.
And one more bug to fix: when compiler/SDBG64 gets overflow or denormal variable it crash with access violation instead of error report like SDBG is doing |
|
Back to top |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Mon Jun 11, 2018 12:00 pm Post subject: |
|
|
Robert,
thanks for the update to the let statement and the addition of the copy to the context menu. I have downloaded this new version (8.30.3) from the web link you mentioned above. Using the let command I could set variable idum8 to 1 as expected.
However, command
Code: |
let idum8 = 2147483648
|
still does not work in my opinion. This command results in
which I think is not correct.
Note: 2147483648 equals 2**31 which is 1 more than MAX_INT (2147483647). For variable idum (which is of type INTEGER*4) this result is ok and it is shown by sdbg64 for idum after having executed the let statement:
However, idum8 is of type INTEGER*8 !!!
I changed the original test programme to sdbg_test1.for:
Code: |
integer*4 idum
integer*8 idum8,idum88
idum=2147483647
idum8=2147483647_4
idum88=2147483648
write(*,*) 'idum=',idum
write(*,*) 'idum8=',idum8
write(*,*) 'idum88=',idum88
idum8=idum8+1
write(*,*) 'idum8=',idum8
end
|
and compiled it using command
Code: |
ftn95 sdbg_problem1.for /debug /64 /link
|
Executing sdbg_problem1.exe resulted in output lines
Code: |
idum= 2147483647
idum8= 2147483647
idum88= 2147483648
idum8= 2147483648
|
This shows that idum8 and idum88 work in the code and executable as expected.
Moreover: the ftn95 command mentioned above resulted in
Code: |
WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
INTEGER(KIND=4)
|
Finally I tried using assignment
which however resulted in
Code: |
*** Invalid KIND specifier
0006) idum88=2147483648
WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
INTEGER(KIND=4)
1 ERROR, 1 WARNING [<main program> FTN95 v8.30.0]
*** Compilation failed
|
I wonder if sdbg64 still has a problem here.
Regards,
Dietmar |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8211 Location: Salford, UK
|
Posted: Mon Jun 11, 2018 4:08 pm Post subject: |
|
|
Dietmar
I am not familiar with the details but if you put
into an FTN95 program then the kind value is out of range unless you are using /alt_kinds. Otherwise default values are in the range 1 to 4. |
|
Back to top |
|
 |
Robert

Joined: 29 Nov 2006 Posts: 457 Location: Manchester
|
Posted: Tue Jun 12, 2018 8:43 am Post subject: |
|
|
It looks like you are correct, 64-bit constants are truncated to 32-bit (in sdbg and sdbg64). I will look at it. |
|
Back to top |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Jun 12, 2018 8:54 am Post subject: |
|
|
Paul,
thanks for your hint, I tried it and command Code: |
ftn95 sdbg_problem1.for /alt_kinds /debug /64 /link
|
did not produce the error any more (having added _8 to the constants of the assignments to idum8 and idum88 in the ftn95 code mentioned above).
Regards,
Dietmar |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8211 Location: Salford, UK
|
Posted: Tue Jun 12, 2018 11:03 am Post subject: |
|
|
Dietmar
It would be safer to avoid /alt_kinds and append _4 (for example).
Hopefully all the bugs relating to /alt_kinds have now been fixed but I am not that confident. |
|
Back to top |
|
 |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 14, 2018 1:27 pm Post subject: |
|
|
Currently I am using sdbg64 quite often when porting a GUI application from 32 to 64 bit. I happened to run into a subroutine containing ENTRY statements und unfortunately could not set breakpoints in the lines after the entry statements. This works for the 32 version of ftn95/sdbg.
Please look at file myentry_subroutine.for
Code: |
INTEGER*4 MYINT,MYRESULT
MYINT=33
call SR1(MYINT,MYRESULT)
write(*,*) MYRESULT
call SR2(MYINT,MYRESULT)
write(*,*) MYRESULT
call SR3(MYINT,MYRESULT)
write(*,*) MYRESULT
end
SUBROUTINE SR1( MYINT,MYRESULT )
INTEGER*4 MYINT,MYRESULT
MYRESULT = MYINT
RETURN
ENTRY SR2 ( MYINT,MYRESULT )
MYRESULT = 3 * MYINT
RETURN
ENTRY SR3 ( MYINT,MYRESULT )
MYRESULT = MYINT + 1
RETURN
END
|
and compile it via
Code: |
ftn95 myentry_subroutine.for /debug /link /64
|
I may set a breakpoint to line 16, however, I cannot set breakpoints a lines 20,21,23 and 24 which I should be able to, shouldn't I?
Regards,
Dietmar |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2923 Location: South Pole, Antarctica
|
Posted: Fri Jun 15, 2018 2:06 pm Post subject: |
|
|
I would add similar problem that SDBG64 as opposed to SDBG starts its debugging process at the wrong first line (red line). To reproduce that one can use Polyhedron test suite of Fortran-90 benchmarks which is free for downloading. Take the smallest size fortran sources like channel2.f90 or tfft2.f90 |
|
Back to top |
|
 |
|