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 

Pure devilry catch in debugger

 
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: Sat May 05, 2018 2:48 am    Post subject: Pure devilry catch in debugger Reply with quote

Look at this snapshot. By unimaginable way the SDBG64 succeeded to miss the first red line and stopped only at the second absolutely identical one with the undefined error message.



UPDATE:
i saved the code, double checked that the bug is 100% reproduced but when returned later again the bug disappeared. Double devilry?

Such happened decades ago as indication that i need to reboot computer. Anyone else saw such behavior with unexplainable errors?


Last edited by DanRRight on Sat May 05, 2018 3:29 am; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat May 05, 2018 3:09 am    Post subject: Reply with quote

If kPlot_Ee_Center is 1 and kPlot_Ei_center is undefined, what the compiled code did is quite reasonable. Given an expression (L1 .and. L2), where L1 is false, L2 need not be evaluated to know that (L1 .and. L2) is false; thus, the problem that L2 may depend on undefined variables may not be detected.

The F95 standard has this to say:
Quote:
7.1.7.1 Evaluation of operands
It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely each operand, if the value of the expression can be determined otherwise.


As a general rule, compilers that support detecting undefined variables do not flag the mere presence of such variables; only when one of these variables is used (or queried in the debugger). Otherwise, all of the program memory would have to be checked frequently, and that would consume too much time.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat May 05, 2018 3:15 am    Post subject: Reply with quote

You are probably right, mecej4.

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



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

PostPosted: Mon May 14, 2018 4:18 am    Post subject: Reply with quote

whlst mecej4's explanation is spot on and very well explained I don't see how t could explain why the first test id processed ok and then the third one there's a failure, since if the variable of L2 was undefined it was so in each of the 3 cases (as it is never set between each 'IF' test).

Having said that I just saw the update note of Dan:
Code:
i saved the code, double checked that the bug is 100% reproduced but when returned later again the bug disappeared. Double devilry?

Now, I would say that that is impossible. Computers are infallible (in the sense of give 'em the same code and data n times and you get the same result each time). Thus eiher the code or data had changed.
I recently had some cases where I ran a code, had a problem, changed the code and found no change in behaviour.
It had devilry stamped all over it.
Couldn't understand until I realised that there was an earlier vesion of the exe still running so when I'd re-compiled it wasn't actually creating a new executable, ... and so I was jumping the gun and off and re-running the original !
(I was so trusting that I hadn't actually read the line where it said it couldn't create the executable ! I think it's called the blind (me) fooling the blind (me) ! Usually signifies the need of coffee (anti-devil brand) intake and a break Smile )

It's a bit like checking inout data ... remember these wise words, which once inhabited some obscure corner of the NASTRAN manuals about 30 yeas or so ago ... "when it comes to checking input data, don't trust anyone, not even your grandma" and you could usefully add to that ... ' and especially not yourself' !
There was another equally profetic one comparing NASTRAN users with pioneers in the early days of america ... stating that bad(inattentive) ones get eaten by grizzly bears Smile
Since finding those I always since ask myself 'what have I done wrong' and I never take 'nothing' for an answer ... as is usually proven to be the correct procedure !
_________________
''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
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon May 14, 2018 6:52 am    Post subject: Reply with quote

Checking input data should include checking that data is input AND that the input values are correct. If a program uses undefined variables, those are variables that should have been given values earlier, by assignment or a READ statement but, because of programmer error, have been left undefined.

Consider a program that solves a quadratic equation A x^2+B x + C = 0. By mistake, the program does READ *, A,B; as a result, the program uses C without defining it. If you only check that A and B have correct values, and do not notice that C has been left out of the READ statement, you would find that running the program with the same values of A and B gives a different set of results from run to run, and the program may even crash sometimes.


Last edited by mecej4 on Mon May 14, 2018 11:08 am; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon May 14, 2018 10:15 am    Post subject: Reply with quote

I'd add to the above a check that the input data is actually input data for the program in question, and the correct version.

If the data file starts with something like:

'DannyBhoy version 39.01'

You can check that it is data for DannyBhoy.exe, but also it may not be compatible with an earlier version of the program, e.g. from version 32.00 the program may expect more or different data. In my case, such a change was adding the RGB values for all the material types, rather than letting the program decide.

It is a considerable annoyance to me that recent versions of my favourite, CorelDRAW!, won't read old files. However, you can fix this by having the appropriate version-dependent input facilities, then you can read old files.

In Mecej4's example, even if C has been initialised, you get the same answer every time, just that mostly they are wrong (in the sense that they aren't what the user expects). The program delivers the correct answer - maybe - to the problem given).

Sometimes too aggressive a check on data values can inhibit the use of the program. For example, checking that the unit weight of rock or soil is greater than 15 kN/m^3 stops you using the program on the moon or Mars, and even if earthbound, prevents you analysing problems involving peat or lightweight fills.

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



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

PostPosted: Tue May 15, 2018 10:05 pm    Post subject: Reply with quote

Problem solved for inter-planetary ftn95 work by adding additional check that the correct density is used for the location Wink

As usual the ols addage of 'rubbish in = rubbish out' comes to the fore, where 'rubbish' is not always what you think it is/should be.

Tis is in fact why computer/robots ... sorry AI ...... is ust that and no one should ever consider buying an automated vehicle, for example
!
_________________
''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
Page 1 of 1

 
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