![forums.silverfrost.com Forum Index](templates/subSilver/images/logo_phpBB.gif) |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Sat Sep 09, 2017 12:10 am Post subject: This is why it is important to have a lot of users |
|
|
Software has bugs, my own one specifically. Some bugs are so hidden that I call them "devilry". Look what the devil's nail I catched.
In the hurry years ago I made a mistake writing something like
instead of
and got sometimes strange "access violation" crashes (crashes got on my nerve lately). Bug was disappearing if I changed something or used /DEBUG and then reappearing again. Finally after 10 years, tired hiding or retired, this devil gave up and I got its demo. The fact that it is 100% reproducible is un-be-lie-vable, isn't it?
Code: | A =1.234567
B =2.345678
if(A.lt.A) then
B = 0
endif
end |
Do I live in the Matrix or need some extreme form of exorcism for atheists? )))) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Sep 09, 2017 3:50 am Post subject: |
|
|
The error happens only when generating 32-bit code.
Analysing the bug involves looking at the instruction codes generated.
The code listing (/EXP) shows
Code: | 0000002e(18/4/9) fld A
00000031(19/4/9) fcomp fr0,fr0
00000033(20/4/9) ffree bh
00000035(21/4/9) wait
00000036(22/4/9) fstswax
00000038(23/4/9) sahf
00000039(24/4/9) jae __N3
|
The third instruction is nonsense -- you can only free the X87 registers. Perhaps, FFREE FR0 was intended. By using an FCOMPP instead of FCOMP in the second instruction, the FFREE would have been made unnecessary.
Disassembly of the OBJ file shows
Code: | 0000002E: D9 45 EC fld dword ptr [ebp-14h]
00000031: D8 D8 fcomp st(0)
00000033: DD BF 9B DF E0 9E fnstsw word ptr [edi-611F2065h]
00000039: 0F 83 07 00 00 00 jae 00000046
|
The access violation is apparently caused by the third instruction, which is using a bad offset. Byte 34 should have been C0, which would have given the following three instructions:
Code: | ffree st(0)
wait
fnstsw ax
sahf
|
Errors of a slightly different nature occur when /p6 is used.
Code: | 0000002e(18/4/9) fld A
00000031(19/4/9) fcomip fr0,fr1
00000033(20/4/9) fcomp fr0,fr0 ; Clean up the coprocessor stack
00000035(21/4/9) jbe __N3
|
The first comparison instruction refers to FR1, but that register has not been loaded. The FCOMP instruction not only pops the stack, but also affects the flags.
Last edited by mecej4 on Sat Sep 09, 2017 1:59 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Sat Sep 09, 2017 8:27 am Post subject: |
|
|
Thanks for the feedback Dan and for the explanation mecej4. I have logged this as needing fixing. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Sep 09, 2017 11:28 am Post subject: |
|
|
Does it happen for IF (A .gt. A) ?
Probably no-one reported it, because no-one ever did it before.
Makes you wonder where you go to with an ELSE, or
GOTO (A-A) 10, 20, 30
One could waste a whole day, or worse longer, on this.
Seriously, if the correct answer to generate code that works assuming the programmer's intent is explicit, or should it generate an error message or warning at compilation? By analogy with the warning when you compare something to zero, I suspect the latter is better - or both the warning and the correct executable.
Eddie |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Sep 09, 2017 12:51 pm Post subject: |
|
|
Quote: | Does it happen for IF (A .gt. A) ? |
Yes, it does.
The situation is complicated in more recent versions of Fortran when A, B or both can be NaNs, or if one compares a REAL to an INTEGER.
I sometimes wish that we had a logical type with three possible values, TRUE, FALSE and "UNKNOWABLE" to handle such situations.
By the way, the venerable FTN77 4.03 compiler generates correct code for Dan's test program.
Last edited by mecej4 on Sat Sep 09, 2017 1:43 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Sep 09, 2017 1:16 pm Post subject: |
|
|
Wow,
That's amazing. I think the problem of comparing a variable with itself ought to be recognisable as a programming error, but I would not expect a compiler to recognise this as the same case:
Code: | B = A
IF (A .LT. B) THEN |
As far as LOGICALs go, since one bit pattern is .TRUE. and another is .FALSE., then even LOGICAL*1 has plenty of spare bit patterns to represent shades of the truth. Perhaps there is a need for a new type: POLITICAL perhaps, where every shade between .FALSE. and .TRUE. can be represented?
Eddie |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Sep 09, 2017 1:17 pm Post subject: |
|
|
Paul, I recognise that SDBG is probably not meant for detailed machine code level work, but it does offer a disassembly window (accessed with F11), which is sometimes quite useful.
While using this feature with Dan's program, I found the following deficiencies:
1. The NOP instruction, opcode 90h, is disassembled as INT 3, which has the opcode CCh.
2. The disassembler appears to be unaware of P6 instructions, such as FCOMIP, which are generated by the FTN95 compiler when the /P6 option is used. The disassembler simply shows DB (data byte) codes for each byte in this two-byte instruction:
Code: | 401034 DB DF
401035 DB F1
|
instead of
Code: | 401034 FCOMIP FR0, FR1
|
It would be nice to be able to display the code bytes (in hex) along with the mnemonics in the F11 window.
Last edited by mecej4 on Sun Sep 10, 2017 2:04 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Robert
![](http://forums.silverfrost.com/images/avatars/141724757f4c9c04bd.jpg)
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Sun Sep 10, 2017 11:46 am Post subject: |
|
|
It is fantastic that people use the F11 assembler window in sdbg. I will amend the disassembler to include the P6 instructions and include the instruction bytes (like sdbg64 does). |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Tue Sep 12, 2017 2:49 am Post subject: |
|
|
If I correctly understood that after fixing this bug there will be no access violation. But doesn't this mean that we will never find similar bugs in the future ??? I support Eddie's comment that this has to be considered as user's error
Respect to exorcism mecej4 implicitly hinted that I have to learn assembler and computer codes. No, not only I will not do that but will stress again and again that the debugger never has to switch to assembler by itself, only do that if user asks explicitly. In such cases there is usually no debugging information because the code was compiled with /nocheck. To not to scare novice programmers I suggest to babysit them as much as possible. The debugger in this case has to be very verbose and show warnings that this happened due to /nocheck in this particular subroutine and instruct user that some further debugging still can be done.
Last edited by DanRRight on Tue Sep 12, 2017 3:41 am; edited 3 times in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Sep 12, 2017 3:32 am Post subject: |
|
|
Dan, there is no strict relation between compiler option /check and the access violation. In fact, had Byte 34 been C0 instead of the erroneous BF, there would not even be a memory access, let alone an illegal memory access. Nor can you expect the debugger to catch lapses in the code generator. On the other hand, without the code generation bug, there would have been no access violation and your A.LT.A bug would have gone undetected for a longer time.
Consider this modified version of your code:
EQUIVALENCE (A,B)
...
IF (A .LT. B) THEN
...
and suppose that "..." stands for hundreds of lines, and that there is no code generation bug. Running this in the debugger, you would probably not notice that A and B have the same address unless you look at the assembly code.
I am not suggesting that everyone should learn assembler. I am simply pointing out that for detecting certain types of bugs you will have to rely on someone who does; and, if that someone is not you, the bug will probably survive for a longer time than otherwise. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Sep 12, 2017 6:07 am Post subject: |
|
|
Dan,
We all develop code with "devilry".
As we have done this for so many years, we have also developed ways of identifying these code "features" and ways of eliminating them.
Only recently I introduced something like "if(A.lt.A)", by typing too fast and not working in a sound proof room !
We have to test the code, with hopefully sufficient test options to eliminate these features.
I also remember Eddie's recent post of "ftn95 prog /c" where /c did nothing bad for years.
If I could suggest an approach I find helpful (no not /implicit_node) is to use a file compare utility and do an audit of all changes against a past version that appeared to work.
The other is to never give up on searching for any possible "devilry", as while you have a test case that might exposes the bug, it is the best time find it.
What scares me lately is the increase in typing errors that are creeping into my keyboard usage.
John |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Robert
![](http://forums.silverfrost.com/images/avatars/141724757f4c9c04bd.jpg)
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Tue Sep 12, 2017 8:44 am Post subject: |
|
|
Quote: | 1. The NOP instruction, opcode 90h, is disassembled as INT 3, which has the opcode CCh. |
It is correct. When your code is stepped sdbg places INT 3s over the NOPs - that is what the NOPs are for, they are places that INT 3s can be safely placed. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Sep 12, 2017 11:21 am Post subject: |
|
|
John, Your increasing keyboard errors are symptomatic of other things than ageing or carelessness. I have a very small 'travel' laptop that recently stopped recording the letter 'n' - it transpired that it was a tiny bit of fluff (possibly cat hair) under the key, and it probably got there when I cleaned the keyboard, and the problem was resolved by a second clean. Of course keyboards do go bad, but less commonly than in the past. A change of keyboard can work wonders even if it is a user problem as the feel is different.
As for errors like IF (A .LT. A) (and indeed, as well as .GT. perhaps .LE. .GE. and .NE. need checking) and whether you get them via EQUIVALENCE, I can't see the point of equivalencing a single named variable to another. Perhaps someone can enlighten me.
Where EQUIVALENCE comes in useful is for example selecting single integer 'grey codes' from a big array to make them simpler to handle locally, and then the corresponding silly IF would be something like:
IF (i_all_grey_codes(76) .NE. i_grey_code_button_76) ...
(where the two had previously been EQUIVALENCEd.)
I respectfully suggest that coding something like that would be prima facie evidence that one needs to take a vacation.
Eddie |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Robert
![](http://forums.silverfrost.com/images/avatars/141724757f4c9c04bd.jpg)
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Sat Sep 23, 2017 7:32 pm Post subject: |
|
|
Are there any other instructions other than FCOMIP and its variants that do not disassemble correctly? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Nov 15, 2017 5:57 pm Post subject: |
|
|
The bug described at the start of this thread has now been fixed for the next release of FTN95 (after v8.20). |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|