Welcome to our forums
Paul,
as far as I remember I closed the About box window via the close button. But unfortunately I currently cannot reproduce the situation any more. Sorry. If I should be able to reproduce the situation once again, I would send another post.
Regards, Dietmar
Because there was no respond from Silverfrost or users i'm not quire sure if my previous posts about SDBG64 got any attention...Time to cut 3% salary for those who do not use and do not care about debuggers 😃. Seriously, anyone who do not know or do not use them just waste years of their time.
There exist one more small but annoying problem in SDBG64: when you hover your mouse over variable second time the popup menu with the variable value does not appear. You have to touch some other variable and then return back.
I happened to run into another problem for the 64 bit debugger sdbg64 which does not occur for the 32 bit debugger: for the 64 bit debugger I cannot change a variable inside the debugger using the 'let' statement (using menu items 'Tools' and 'Command Prompt').
integer*4 idum
idum=5
write(*,*) 'idum=',idum
end
Now starting sdbg64, selecting menu items 'Tools' and 'Command Prompt' and entering command
let idum = 33
results in error message
Expected '=' after let command
The same proceeding works for sdbg (32 bit).
I am using sdbg64 8.30 as of 11th of March 2018 (approximately). Version information of sdbg64 is
Silverfrost Debugger for 64-bit Windows version 8.30
Copyright Silverfrost Limited 1994-2017
Has anyone observed the same behaviour? What is the newest version of sdbg64?
Regards, Dietmar
Here is a ling to sdbg64 that fixes the 'let' issue:
Good catch, Dietmar. This is probably latest bug, I think LET worked OK when I used it before with 64.
Here is one annoyance of SDBG64 which gets on nerves after doing that hundred times a day (which by the way confirms my decades old suspicion that vast majority of users rarely use debugger preferring to debug Neanderthal's way with inserting Print* while the devs do not use their own software and when issue something new for the users it is always in deep pre-beta state fixing which takes sometimes decades. This Fortran compiler was always the most advanced but unfortunately by far the most buggiest one). Older SDBG was closing itself almost instantly. The newer SDBG64 waits 3 seconds for something hell knows what before doing that.
Do the math: lose just 3 seconds every day and at the end of your life you will lose 24 hours or 3 working days. With SDBG64 you may lose (3 days if lose 3 sec) * (100 times per day) = 300 days or a YEAR !
Take for example the program hello.f95 Print*,' hello' end
compile it ftn95 hello.f95 /64 /debug /link
Launch SDBG64 debugger
SDBG hello.exe
then press ALT+X and it will demostrate how it will waste these 300 days of you life
Dan,
Are you going to make the same mistake 100 times a day for the rest of your life ? ... Imaging how much time you are wasting having a coffee each day; and all the time you have spent moving all over the world.
You should start using implicit none and get rid of most of those bugs. You must be able to do that in less than 300 days !
I'm off for a coffee, as I just found a 'bug' that's been bothering me for 4 years. By your analysis, will I have more time now ?
John
John, Of course we waste hell amount of time on humongous amount of cr#% in the world. Sometimes we can not do anything with it sometimes we can.
I use /UNDEF, which is better then implicit none, John, how may time I repeat this in 3 decades on all Fortran newsgroups and no one hear that?
I copy/paste large variables (and they usually all large for self-documenting) not typing them again and again so there is no source of error for static variables. Also I use new compilation options /NO_TRUNCATE which removes the main source of errors catched by the 'implicit none' - i.e. getting over 72/132 character limit. So my mouse trap is pretty powerful.
It's the logic errors which are the main source of bugs in large codes not just damn static typos. To move even most stupid step ahead in large code (add some new obvious feature for example) i need to review if this will not interfere with the whole older stuff I added for 30 years which is why I make most of errors. All heavily used codes essentially grow and grow and at some point become unmanageable. Even if I have done that 100 times adding new feature is like a head surgery in the web of the source code.
And also the code development is the main source of lost time not run time for those who make codes in physics. BTW, today Saturday just started, but I already have done 30-40 compilations.
To get a proof that /undef is more powerful then 'implicit none' take any large code made by someone which never used /undef but used only 'implicit none' and make a fun of its author showing how many bugs his code has. I guarantee the code's author will spend a month in total #$%^& trying fixing all that.
Quoted from DanRRight To get a proof that /undef is more powerful then 'implicit none' take any large code made by someone which never used /undef but used only 'implicit none' and make a fun of its author showing how many bugs his code has.
Dan. this is a good idea. I shall try it with my graphics code. Is /64 /undef supported, as I have just started using /64 /check ?
Robert,
thanks for the link to the zipfile containing a new version of sdbg64.exe which fixed the problem of setting a variable within sdbg64.
Regards, Dietmar
I put a new version up at that link. It closes the executable much faster. It misses out some cleanup code. Can people report any issues when closing down the debuggee.
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
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
Doesn't the variables window open automatically?
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
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
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
call stack variables
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
Robert,
in connection with a problem previously mentioned I ran in another problem when trying to change an integer*8 variable from within sdbg64.
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
let idum8 = 1
; this resulted in value
-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
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.
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
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
let idum8 = 2147483648
still does not work in my opinion. This command results in
idum8: -2147483648
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:
idum: -2147483648
However, idum8 is of type INTEGER*8 !!!
I changed the original test programme to sdbg_test1.for:
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
ftn95 sdbg_problem1.for /debug /64 /link
Executing sdbg_problem1.exe resulted in output lines
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
WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
INTEGER(KIND=4)
Finally I tried using assignment
idum8=2147483647_8
which however resulted in
*** 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
Dietmar
I am not familiar with the details but if you put
idum8=2147483647_8
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.