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 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: 2813
Location: South Pole, Antarctica

PostPosted: Fri Feb 16, 2018 10:25 am    Post subject: Start using debuggers, people Reply with quote

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
Code:
   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
Code:
ftn95 ccc.f95 /debug /64 /link >z
and run
Code:
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 ?


Last edited by DanRRight on Fri Feb 16, 2018 4:06 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Feb 16, 2018 3:23 pm    Post subject: Reply with quote

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.

Code:
  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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Feb 17, 2018 2:13 am    Post subject: Reply with quote

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

/* 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
Code:
a=1e20
b=1e20
c=a*b
end


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 ?).

Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Feb 19, 2018 3:06 am    Post subject: Reply with quote

Dan,
There's nothing wrong with releasing beta software per say, but the problem, which you allude to, is the level of maturity at which it is released.
I agree with you that sometimes I cross software which has obviously been chucked out without even the slightest testing.
Time is money as the saying goes, and there's the rub.
As in many businesses these days financial (and hence time) considerations take precedence over anythinf & everything.
The situation is exacerbated by the seeming inability for professionals to actually be able to estimate how long something will take to develop (not limited to software this one) and the corresponding result that products are almost always 'late' in hitting deadlines.
There's nothing wrong with standing up to your boss and saying 'sorry it can't be done' and then putting forward a different alternate strategy.
Of course the problem there is that there's almost always somene in an organisation who will claim it can be done, persuade the boss thay can do it, and then bugger off when the proverbial hits the fan leaving those who said it couldn't be done to be chastised for not being able to recover from the mess in an unreasiìonably (and often unconsulted upon) specified time.
At this point, in the software world, often comes a beta release.
It's a 'get something - anything- out of the door quick'scenaqrio.

As an example: of his 'modern' way of doing things:
I've come across this in my domain (engineering).
Finite element models need to be checj'ked before they are delivered to a customer.
I have many times been on the receiving end of absolute dross in such circumstances. Often from company's who should and do know better but send it on a project managers instructions in order to meet a deadline.
It's done because they know that almost always the poor sod who receives it will be told by his boss to sort it out.
That attitude is called blackmail, silent blackmail but blackmail none the less. It's also criminal because you end up doing work that someone else is paid to do and doesn't.
So the work is actually paid for twice ! No surprise when costs ALWAYS overrun then.

The worst case I've seen was when a model was supplied in a completely unusable format (using a program called COSMOS).
It needed to be in the universal standard NASTRAN format.
The call was put out.
A model was created, and received, in NASTRAN format. So far so good.
Ahh, but the model's component parts weren't actually connected, you see the company concerned had used some of those very clever contact elelments to stick them together and their 'translator' couldn't cope could it. Amnd then remember they don't check anything do they so across the model came.
I still have no idea to this day if they ever produced an acceptable model or not - no manager ever informed me of the outcome. No surprise there then.


I'm sure the equivalent thing happens in the software world. Leading often I'm sure to immature beta versions.


I agree with you Dan - you can, and indeed should, rely on some user input for 'tweaking' of software, but to sytematically shove it off the shelf is counter-productive imo.
Users ar no fools and word spreads quickly when it happens.
If your software is the only cookie in the biscuit tin you can get away with it because your audience is captive, but in the alternate case all you do is make your competitors rub their hands with glee.

There is one thing worse than beta-dumping - that's making changes and/or improvements (in your eyes) to a program without consulting your user-base in advance to get the basics right.
There's nothing worse than producing something which doesn't do what it says it does on the tin ... .though producing something nobody needs/and-or/wants comes a close second.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Mon Feb 19, 2018 3:08 am; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Feb 19, 2018 3:07 am    Post subject: Reply with quote

All this comes down to another good point you make Dan - experience counts enormously in these situations and is often sadly lacking, usually at nanagement level, sometimes on the technical management side but ALWAYs on the project management side where only the bottom line counts and solution to a technical problem consists of 'let's not do that then - how can we justify not doing it'.
In recent years one of the most damning examples (in the engineering sphere) was the Space Shuttle O-ring seals criminal dereliction of duty, for which no-one swung as I remember.
Eh ... is that 'time is money' ringing out over the intercom.

... which, talking about cost, leads me nicely into .... the perfect ...

'Ode to Project Managers' ...

"Seems like everybody's got a price
I wonder how they sleep at night.
When the sale comes first
And the truth comes second
Just stop, for a minute and
Smile
Why is everybody so serious!
Acting so damn mysterious
.
.
Can we all slow down and enjoy right now
Guarantee we'll be feelin
All right."


... all managers should be forced to watch THIS first thing every morning and the world would be a beter place ...
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Mon Mar 12, 2018 11:02 pm; edited 4 times in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Feb 27, 2018 2:49 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Tue Feb 27, 2018 2:10 pm    Post subject: Re: Reply with quote

DanRRight wrote:
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.

DanRRight wrote:
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.
Code:
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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Feb 27, 2018 7:27 pm    Post subject: Re: Reply with quote

mecej4 wrote:
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 Smile

mecej4 wrote:
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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Mar 04, 2018 5:01 pm    Post subject: Reply with quote

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"
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Mar 06, 2018 1:36 am    Post subject: Reply with quote

The use of the debugger is a bit of a black art, adding a layer to the learning curve which probably puts a lot of people off using it.

The Debugger would be an excellemt subject to be treated by on of Paul's Youtube videos, assuming he has the time.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Thu Mar 08, 2018 10:10 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Tue Mar 06, 2018 3:25 am    Post subject: Reply with quote

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



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

PostPosted: Tue Mar 06, 2018 6:56 am    Post subject: Reply with quote

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



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

PostPosted: Tue Mar 06, 2018 5:38 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu Mar 08, 2018 10:25 pm    Post subject: Reply with quote

mecej4 wrote
Quote:
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.

Ahhhhhhh !!! problemo no. 1 in my case !

The link you posted btw is a theoretical overview , myPaul-vid suggestion was linked to practical reality specifically SDBG.

Dan, thanks a lot for your QuickGuide, much appreciated.
It's like a great 'cheat-cheet' - a philosophy which could come in useful for improving documentation for many things in FTN95.

Having been inspired to try out SDBG back to work .... now where did I say to put those PRINT*'s ... ah yes ..... Wink
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Mar 09, 2018 9:55 am    Post subject: Re: Reply with quote

John-Silver wrote:
mecej4 wrote
Quote:
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.

Ahhhhhhh !!! problemo no. 1 in my case !

The link you posted btw is a theoretical overview , myPaul-vid suggestion was linked to practical reality specifically SDBG.

Dan, thanks a lot for your QuickGuide, much appreciated.
It's like a great 'cheat-sheet' (or 'Quick Reference' if you're sensiti to the 'c'-word)- a philosophy which could come in useful for improving documentation for many things in FTN95.

Having been inspired to try out SDBG back to work .... now where did I say to put those PRINT*'s ... ah yes ..... Wink

_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
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 1, 2, 3, 4  Next
Page 1 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