View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Fri Apr 06, 2018 12:35 am Post subject: |
|
|
1) The bug mentioned at the beginning of this thread is still there in SDBG64 ver.8.30 which does not show variable B if you either step on it by the mouse or right click on it to open new window with the variable value. Still only shows the IF logical condition is true or false.
Showing logical condition of IF probably is good idea too as an upgrade to older SDBG but it has to be done with the special key combination+mouse devoted to it (with Shift or CTRL keys pressed). Or better both the variable A or B together with IF status have to be shown at the same time in the same popup windows
2) The first line the debugger showing for the first time when you load the program is still wrong by 1 line (it lands on second executable line). Line numbering of SDBG64 coincide with the one in my own editor
3) But strange is that due to another similar bug the debugger sometimes tells that some lines can not be a breakpoints. And the fun is that there is no explanation for that effect based on one line miss. And even more fun is that if there exist one line of text separated by the empty area before and after it the debugger accepts this line as a breakpoint.
4) when you are stepping on the variable with the mouse, the value of the variable in yellow window appears not reliably. So you are "flying" over it and flying, tapping and tapping, stepping and stepping, sometimes even clicking on it to see the value. 32bit SDBG works here with no problems.
5) The windows containing list of variables used in given subroutine still miss the user-defined Parameter variables which always must be there with just the /debug. The Clearwin.ins, Windows.ins, OpenGL.ins etc parameters do not have to be in the list.
6) Allocatable variables allocated in another subroutine but used in this subroutine are also missing in the list of variables
7) The Variable Window which prints content of single variable or Total Variable list of all variables shows them in incomprehencible F format with gazillion digits like -6224736787565.00. The user can not change that to something useful (for example 1Pe15.12 so that same number will look -6.224736787565E12 )
In summary, in 8.30 some bugs were fixed, for example I can now restart the debugger keeping breakpoints, linker also shows mismatch of COMMON blocks, which immediately gave me 6 errors, but also some elementary things were not. The debugger still behaves a bit irrationally, it may miss by one line or not miss, it may also ignore some lines as if they do not exist.
My over the quarter century experience with this compiler tells me that developers do not use their own debuggers or do not use Fortran at all. The compiler would win if developers also offered paid consultancy of debugging users' codes. Then they would experienced the bugs themselves and fixed them much faster.
Last edited by DanRRight on Mon Apr 09, 2018 12:12 am; edited 2 times in total |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Apr 08, 2018 10:35 am Post subject: |
|
|
CONTINUED
1) Here is an example and proof how SDBG64 confuses lines and not allowing to use them as a breakpoint (line 1030) - do you see the absence of dot at the left? Debugger decides that this line is a comment or continuation
2) An example of displaying variable in F instead of 1pE format or any other user has to decide when no human can understand its value
Last edited by DanRRight on Sun Apr 15, 2018 11:55 am; edited 1 time in total |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Apr 13, 2018 2:58 pm Post subject: |
|
|
Hello,
here are some more observations concerning sdbg64, version 8.30, which might be of interest.
Selecting menu "Help", submenu "About Debugger ..." does not result in a window displayed
Menu "Windows" does not contain submenu entries "Watches" and "Open Units" (as for the 32 bit version of the debugger)
Command
shows the version of sdbg64 (which should as well be the case using "About Debugger ..."). Are there other options for sdbg64.exe which might be of interest?
I cannot get information about the open units from within the commands tool by using the streams command, because the streams command is currently not available.
Regards,
Dietmar |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Apr 16, 2018 2:34 am Post subject: |
|
|
Usually Paul quickly responds on all posts besides SDBG, which may mean I guess that the support and development of debugger is more someone else responsibility. Worrying though, was it heard what we say above ? |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 446 Location: Manchester
|
Posted: Tue Apr 17, 2018 10:23 am Post subject: |
|
|
Quote: | Selecting menu "Help", submenu "About Debugger ..." does not result in a window displayed |
Really? It shows the copyright notice for me.
Command line options:
/params (or /p) passes subsequent switches to the program being debugged
/sourcepath or /sp sets the path to find source code. This is useful when the source code is in a different place to where it was built. For example:
sdbg64 custprog /sp c:\temp\cust1;c:\temp\cust1\utils
If the source is 'elsewhere' then without a source path option the source will not appear. At this point you can right-click the empty window and select 'Find source file'. Sdbg64 will also use the environment variable SOURCHPATH if set.
/runto sets a breakpoint at the desired location. For example:
sdbg64 dashboard /runto mainui.f90 103 |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Apr 17, 2018 11:38 am Post subject: |
|
|
Robert,
yes, sdbg64.exe shows the copyright information when clicking the about box, but only once in my environment
As a consequence of clicking HELP + ABOUT the complete menu line is greyed. If I click HELP once again (which I would not expect to be able to as the menu line is greyed) then the menu line is shown "ungreyed" again; I may click ABOUT but nothing happens.
Looking at the resource monitor I see that dlls salflibc64.dll and clearwin64.dll have been loaded by sdbg64.exe from the Salford 8.30 environment.
Regards,
Dietmar |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 446 Location: Manchester
|
Posted: Tue Apr 17, 2018 5:30 pm Post subject: |
|
|
That doesn't happen for me. As soon as the about box disappears the menu bar is redrawn in black. The menu bar looking disabled is a standard Windows feature. You can try it in Notepad. Go to Help->About and the menu bar with disable and then presumably reenable.
Do you only see this for Help->About? |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Apr 18, 2018 10:22 am Post subject: |
|
|
Robert,
the scenario for notepad you described works in my environment in the same way you described (and as expected).
Let me describe another obeservation in this context. If starting sdbg64 and selecting menus
then the "Find Routine" window pops up. Leaving this window (via Cancel button) and selecting the Help/About menu entries, results in
Code: |
no About window is displayed
the Tools/"Find Routine" menu entries may be selected, however, the "Find Routine" window is not displayed any more
|
The same applies for all other menu entries (after having selected menu Help/About): none of the windows corresponding to two menu entries (menu and submenu) selected, are displayed any more.
If the Help submenus are not selected the menu/submenu entries caused the corresponding window to be displayed.
Regards,
Dietmar |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Apr 22, 2018 5:08 pm Post subject: |
|
|
Few more suggestions to add to SDBG64 which SDBG has but 64bit one does not. To synchronize both debuggers couple these things need to be added to 64bit debugger:
1) when you right click on variable the small window opened which shows value of this variable is often too small for long variables and
2) additional right click on this small variable window shows nothing. The SDBG though shows 4 options (Write break on variable etc) which is very convenient instead of go the kilometer long list of variables window and set the break there.
3) as we discussed, i suggested to make PARAMETERS always visible to the debugger with any debugging switches.
John Campbell made potentially modification, suggesting also to always show PARAMETERS at any debug switches be it /debug or /full_debug but only if you hover the mouse over its name and do not add them into the VARIABLES window.
Mecej4 suggested to add PARAMETERS window.
I also suggested if PARAMETERS or VARIABLES y belong to CLEARWIN.INS, WINDOWS.INS OPENGL.INS etc do not show them in the VARAIBLES window if /DEBUG key is used. FULL_DEBUG can show everything.
Please consider all these suggestions |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Mon Apr 23, 2018 7:54 am Post subject: |
|
|
Dietmar
You need to close the "About Debugger" window before doing anything else.
You can't leave it open and then open another one like it. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Mon Apr 23, 2018 11:02 am Post subject: |
|
|
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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat May 26, 2018 9:39 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Jun 01, 2018 1:20 pm Post subject: |
|
|
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").
Code: |
integer*4 idum
idum=5
write(*,*) 'idum=',idum
end
|
Now starting sdbg64, selecting menu items "Tools" and "Command Prompt" and entering command
results in error message
Code: |
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
Code: |
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 |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 446 Location: Manchester
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Jun 03, 2018 1:49 am Post subject: |
|
|
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 Code: | Print*,' hello'
end |
compile it Code: | ftn95 hello.f95 /64 /debug /link |
Launch SDBG64 debugger
then press ALT+X and it will demostrate how it will waste these 300 days of you life |
|
Back to top |
|
|
|