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 

Start using debuggers, people
Goto page Previous  1, 2, 3, 4  Next
 
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: 1822
Location: South Pole, Antarctica

PostPosted: Fri Apr 06, 2018 12:35 am    Post subject: Reply with quote

1) The bug mentioned at the beginning of this thread is still there in SDBG64 ver.8.30
Code:
if(A.lt.B) then
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
View user's profile Send private message
DanRRight



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

PostPosted: Sun Apr 08, 2018 10:35 am    Post subject: Reply with quote

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
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 125

PostPosted: Fri Apr 13, 2018 2:58 pm    Post subject: Reply with quote

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

    sdbg64.exe /Version

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



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

PostPosted: Mon Apr 16, 2018 2:34 am    Post subject: Reply with quote

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



Joined: 29 Nov 2006
Posts: 236
Location: Manchester

PostPosted: Tue Apr 17, 2018 10:23 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 125

PostPosted: Tue Apr 17, 2018 11:38 am    Post subject: Reply with quote

Robert,

yes, sdbg64.exe shows the copyright information when clicking the about box, but only once in my environment Sad

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



Joined: 29 Nov 2006
Posts: 236
Location: Manchester

PostPosted: Tue Apr 17, 2018 5:30 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 125

PostPosted: Wed Apr 18, 2018 10:22 am    Post subject: Reply with quote

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

Tools
Find Routine

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



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

PostPosted: Sun Apr 22, 2018 5:08 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 23, 2018 7:54 am    Post subject: Reply with quote

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
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 125

PostPosted: Mon Apr 23, 2018 11:02 am    Post subject: Reply with quote

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



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

PostPosted: Sat May 26, 2018 9:39 pm    Post subject: Reply with quote

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 Smile. 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
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 125

PostPosted: Fri Jun 01, 2018 1:20 pm    Post subject: Reply with quote

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

let idum = 33

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



Joined: 29 Nov 2006
Posts: 236
Location: Manchester

PostPosted: Sat Jun 02, 2018 12:21 pm    Post subject: Reply with quote

Here is a ling to sdbg64 that fixes the 'let' issue:

https://www.silverfrost.com/public_downloads/sdbg64.zip
Back to top
View user's profile Send private message Visit poster's website
DanRRight



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

PostPosted: Sun Jun 03, 2018 1:49 am    Post subject: Reply with quote

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
Code:
SDBG hello.exe

then press ALT+X and it will demostrate how it will waste these 300 days of you life
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
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