Start using debuggers, people

And do report the bugs and problems! Seems all still keep procrastinating and do not like to adopt better way of debugging then neanderthals Print* Everything... I judge that by some on-a-surface bugs people fail to report or at least to discuss if these are not bugs but some not obvious new features.

Here in this code ccc.f95

   a = 0
   b = 1 
   c = 2
  
   if(a.lt.b.and.b.lt.c) then
     print*,' Some xdfsdfsdf'
   endif
   end

compiled as usual in command prompt ftn95 ccc.f95 /debug /64 /link >z and run sdbg64 ccc.exe

you can see hovering the mouse over IF expression that SDBG64 does show in the yellow popup window value of variable a (i omitted that, but just believe me) but not variable b and c. And instead it is trying to show the result of logical operation and also doing that incorrectly as the result is TRUE. The 32bit debugger SDBG does not show the result of logical operation but shows all three variables OK

Since this is new feature, may be i miss how to see in popup window either variables or logical expression ?

I tried Dan's short program in SDBG (32-bit) after compiling with FTN95 8.10. A small fault: when I hover the mouse pointer over 'IF', the debugger attempts to interpret the keyword as a variable, with the pop-up saying:

 IF: no debug information

When I do the same in 64-bit, I run into other problems. In SDBG64 8.10.11, I cannot make the variables pane visible. Pressing F4 seems to transfer focus from the source pane to the invisible variables pane, but enlarging the SDBG64 window to the maximum possible size still leaves the variables pane hidden. When I hover the mouse over the IF statement, what is displayed depends on the location of the pointer.

  Pointer      Pop-up
   on
-----------------------
IF               blank
a                0.000000
First b         a.lt.b= TRUE
Second b     a.lt.b.and.b= FALSE
c                 a.lt.b.and.b.lt.c= FALSE

I suppose that Dan saw the last item. The fourth one does not make sense since b is not of type LOGICAL.

I am running Windows 10-64 (pro) with a 1920 X 1080 monitor.

P.S. I was able to recover the Variables pane in SDBG64 as follows.

1. Start the program in SDBG64 and step over a couple of statements.
2. Change the display setting to Portrait orientation.
3. I found the Variables pane lurking to the far right, and moved it to the left.
4. Change the display setting back to Landscape orientation.

Minor comment: seems 8.20 is a bit different then 8.10 so I do see the entire line ok. Other things are like Mecej4 have described.

One addition is that if use very long variable names, one needs to hover mouse way left to the margin area where there is nothing, no variable, just the empty space, to see the first variable at the left. Other variables are not shown same way as we described above

Together with my previous post few days back where longer variable names were not completely visible if you right click on the variable to show its value in a separate window, and probably also wrong caption positions in native %pl, this all indicates that font length calculation mechanism in FTN95 is in deep beta testing stage

[color=Blue:8208afc75b]/* P.S. I know to write perfect software is very very difficult. This is why i never give my codes to anyone, i know its limits of stability are very narrow. I also do not allow to touch it to anyone otherwise you lose control and the code is quickly dead. Do the original developers of FTN77 still work with FTN95? It feels like this. It feels like Microsoft copied their style (or vice versa, they copied Microsoft) of issuing beta and even pre-beta software to the public instead of making it perfect first, trying all possible limiting cases of software torture users can potentially do, making all the fool-proofing, test on all possible free software and after that never return to millions of further corrections. This is specifically true as the 32 bit version worked well then the question is why with debugger was needed to start from zero? I moving my code to 64bits did not throw out any features of 32bit one, I added more. Stripped down SDBG64 though can not now tell what is the error reason even in this simplest code[/color:8208afc75b] a=1e20 b=1e20 c=a*b end

[color=Blue:8208afc75b] It is Microsoft where each new team writing new version of OS has no experience with writing OSes because they have unlimited resources to hire new people, but how come here in 64bit debugger were so many bugs novices or 'MS procrastinators' only make? With MS it usually takes a half of decade or more before new OS reach quality and stability of older one. With exclusion of SDBG64 which was even worse, a two steps back from SDBG, same was basically true for all versions of this compiler from day one quarter century back: stellar new features of new versions way ahead of everything else on the market and all of them are buggy and half-cooked. Only OpenGL was perfect from day one. FTN77 was great but a crashetron, FTN90 was first Fortran90 PC compiler but only 1% finished and an apotheosis of mess, FTN95 did not crash often but with Fortran90 features was a bugotron which took 10 years to be cleaned. There are a lot of other things waiting in the pipeline like native %PL, making it stable with /optimize and /check, improving Polyhedron test speeds. I even afraid mentioning multithreading and parallelization.

I will tell that this relying on users to report the bugs is very bad habit as they for even 1 billion users operating systems like Windows tend not to report the bugs. Look at 30+ years old Notepad for example if one need a simple proof, doubleclick on any word with following it comma and notice that this damn buggy junk MS editor all used many times highlights the comma too and has also few other bugs (try to highlight bbb here for example aaa+bbb or here aaa.bbb. Try this in your editor. Or even go to MS Office and do the same. See that their left hand does not knows what right hand is doing and users are waiting somebody else will report these bugs ?).

[/color:8208afc75b]

I am shocked that almost no one uses debuggers... Or finding problems do not report them.

When you open SDBG64 debugger and press Ctrl+F to find specific subroutine, SDBG64 finds it but stops on incorrect initial line which is mostly second line of the source text. 32 bit SDBG finds first line OK.

Both debuggers still tell 'Unknown Variable' if this variable was defined as a parameter as if this is not needed for user to be known. I am amazed by passive attitude of people: for 30 years no one reported this and many other similar problems

Quoted from DanRRight I am shocked that almost no one uses debuggers... Or finding problems do not report them.

I have a different view of the role of a symbolic debugger than Dan, and perhaps many other users of FTN95 hold similar views. To me SDBG is one of many tools that are to be used in program development and debugging. Typically, it is a pleasant-to-use tool for (i) debugging small and medium programs, (ii) in the final stages of hunting down a compiler bug and (iii) understanding the structure of a program and relationships between subprograms, arguments, modules, etc. Given this view, I place a much higher priority on the quality of the compiler+linker+RTL than that of SDBG. The facilities provided by /check, /checkmate and /list are far more powerful than SDBG for debugging. Those are the features of FTN95 that make it one of the best compiler packages for debugging. I am happy to overlook deficiencies in SDBG if that will help focus effort on the compiler+linker+RTL.

Consider the variables pane. With a small program, all the variables fit into a medium size frame, and you can see all the variables at once. With a medium size program, you find yourself scrolling the variables pane to find the variables of interest. With a big program, if the variables are not sorted or if you cannot see them grouped by scope (module, common block, subprogram, etc.), it is so time-consuming to step over a CALL and then bring back the variable of interest (to see if/how it changed) that you have to start over and place a watch on that variable, instead. Or, revert to using PRINT statements for a few variables of interest.

Quoted from DanRRight Both debuggers still tell 'Unknown Variable' if this variable was defined as a parameter as if this is not needed for user to be known. I am amazed by passive attitude of people: for 30 years no one reported this and many other similar problems The compiler has to put in extra code to make PARAMETERs have a life in the EXE. Please remember that SDBG64 is quite new, and is getting better.

Here is an example to show that symbolic debuggers have limitations that the user should be aware of.

program sdbg_ex
implicit none
integer :: a=1, b=2, c=3, d=4, e=5,p,q
call sub(a,b,c,d,e,p,q)
print *,p,q
end program

subroutine sub(p,q,f,a,b,c,d)
implicit none
integer, intent(in) :: p,q,f,a,b
integer, intent(out) :: c,d
c=p+f+b
d=q+a
return
end subroutine

Compile with /debug /link and open in SDBG. Here are some things to watch for.

1. The first executable statement is highlited. In the Variables pane, you can see values for a, b, c, d and e. At this point, p and q are undefined, but you will see some junk values displayed. If you hover the mouse over the variables on any line in the main program, you see the same values pop up.

2. Without executing anything, hover the mouse over the variables in the subroutine. You will see values displayed for p, q, etc. with no respect for the fact that the p of the subroutine corresponds to the 'a' of the main program, etc. The subroutine variables are not in scope until the subroutine is entered, but the debugger happily displays 'values'. Behind the scenes, I suspect, SDBG simply finds the name of the variable under the mouse cursor and looks it up in the current symbol table, even though that symbol table does not pertain to SUB.

3. Hover the mouse over 'f' in the subroutine, and you will be told 'no debug information'. What is special about f? There is no variable named 'f' in the main program.

Quoted from mecej4 The facilities provided by /check, /checkmate and /list are far more powerful than SDBG for debugging These features particularly shine if used together with the debugger. Opening debugger at the offending statement is like pro investigation team coming to the crime scene. Most of witnesses are here. And if developers also made saving the data at least one source line prior to the line where error occurred (this is the subject of my suggestion in another thread today) the criminal will be even less likely to escape.

As to your demo code situation, I agree, this uttely simple (but still powerfuil) debugger is a bit stupid here, and devs possibly have to make a note to fix that, but in 30 years I had no confusion with this.

The ability to go back to all previously called subroutines and see what happened there is amazing tool. Putting WRITE on variable or on USE it will save you days of life searching needle in the haystack.

As to using Print* - i used this last time 20 years ago. Good if you succeed to print* all needed variables in offending place but usually you will need to look at much more around. This may take pretty amount of time to wait till the error occurs again. With using debugger all becomes automatically ready at exact time and exact place with all the variables at your disposal. It is so much more pleasant, natural and logical then with just using primitive Print*. Latter ones rise in my head some dark emotions of my Neanderthal past.

With larger codes benefits of SDBG are actually even greater then with smaller ones. Each error there causes shock that you will again waste days because you suspect everything. Without debugger i'd be dead already. As to scrolling long list of variables, I scroll 3 orders of magnitude larger size 4-5 dimensional arrays pretty often and complaining in the past about a lot of things did not yet complain about this kind of difficulty 😃

Quoted from mecej4 The compiler has to put in extra code to make PARAMETERs have a life in the EXE We discussed this few times here and i thought this feature is already fixed. This has to be a default without any additional /switches

One more problem with the SDBG64 ver. 8.20+: when i try to 'Restart Program', SDBG64 fails to do that creating the screen 'Status: Program Terminated'. Repeating with the 'Restart Program' gives no effect.

With some demo programs 'Restart Program' produces crash fatal error. The message 'Assert failure. expr=event.dwProcessid file = DebuggedProcess.cpp file=296'

See https://en.wikipedia.org/wiki/Debugger .

Among symbolic debuggers, SDBG is simple and effective. As long as you do most of your debugging at the Fortran (rather than assembler) level and your program is well-structured, it is adequate.

John,

The only documentation what i had to read about SDBG was how to start it. I will write this to you and everyone. First you compile your program yourprog.f95 with /DEBUG switch and then run both the debugger SDBG and your program simultaneously:

C:\>SDBG yourprog.EXE

This will run for both 32 and 64 bit debugger automatically. That's all. This is the most difficult thing in life : to start anything.

Everything else in SDBG was made ultimately intuitive, click on everything and you will learn in less then 20 seconds, no need to read further this my post. Damn, you are still reading.... OK, in summary,

• push F7 and see how program runs line by line.
• hit F6 if you want to run non-stop till the error or end occur.
• with F2 you can make the mark on the source text till what the code will run and stop. Then press F6 to start the code execution. It will stop exactly at this marked line
• Step over (jump over) few lines with F3.

That were exactly whose 20 seconds you need in 99% cases.

Few more tricks you will learn in the next 20 seconds yourself after trying these above. Most important from them are that you can

• change any variable with 'LET variable=value' in command prompt,
• search for subroutines with Ctrl+F , and
• stop the debugger on any use or write to the specific variable you chose.
• see which files and their units are open

I think i saw the video about using debugger few years back. It had nothing new to me, as the above is almost all what is needed (possibly this movie was for the PLATO, which uses the same debugger)

I added above that to use SDBG you need to compile your sources with /debug or /checkmate switches, latter one being an equivalent to using few other switches /full_debug /check /undef simultaneously if I am not mistaken.

Start using debugger, it is not the kings' business to torture themselves without debugger like a slave on plantation.

By the way one cool feature of SDBG allowing to change any variable would shine future debugger if developers succeed adding 'go back one step' in full form (recovering the state and all variables of this line). If error happen you will go back one step, change the offending variable and try to run the code further. Isn't it cool?

1. The bug mentioned at the beginning of this thread is still there in SDBG64 ver.8.30 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.

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

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

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 ?

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

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

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?

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

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

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

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

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.